From daniel at dgnetwork.com.br Mon Jul 1 20:00:05 2013 From: daniel at dgnetwork.com.br (=?ISO-8859-1?Q?=22Daniel_D=2E_Gon=E7alves=22?=) Date: Mon, 01 Jul 2013 17:00:05 -0300 Subject: [OmniOS-discuss] ZFS Checksum problem Message-ID: <51D1DFC5.9090504@dgnetwork.com.br> I'm having trouble checksum in my ZFS pool, I tried to change data cables and power of HDDs, but the problems remain. All 8 HDDs that are exhibiting errors are identicaland all is on the same controller. NAME STATE READ WRITE CKSUM STORAGE01 DEGRADED 0 0 347 mirror-0 DEGRADED 0 0 188 c15t35d1 DEGRADED 0 0 188 too many errors c15t18d1 DEGRADED 0 0 188 too many errors mirror-1 DEGRADED 0 0 170 c15t21d1 DEGRADED 0 0 170 too many errors c15t22d1 DEGRADED 0 0 170 too many errors mirror-2 DEGRADED 0 0 164 c15t17d1 DEGRADED 0 0 164 too many errors c15t19d1 DEGRADED 0 0 164 too many errors mirror-3 DEGRADED 0 0 172 c15t24d1 DEGRADED 0 0 172 too many errors c15t23d1 DEGRADED 0 0 172 too many errors mirror-5 ONLINE 0 0 0 c15t25d1 ONLINE 0 0 0 c15t27d1 ONLINE 0 0 0 mirror-6 ONLINE 0 0 0 c15t26d1 ONLINE 0 0 0 c15t28d1 ONLINE 0 0 0 mirror-7 ONLINE 0 0 0 c15t29d1 ONLINE 0 0 0 c15t31d1 ONLINE 0 0 0 mirror-8 ONLINE 0 0 0 c15t32d1 ONLINE 0 0 0 c15t30d1 ONLINE 0 0 0 logs mirror-4 ONLINE 0 0 0 c14t1d0 ONLINE 0 0 0 c14t3d0 ONLINE 0 0 0 cache c14t4d0 ONLINE 0 0 0 Smartinfo: c15t17d1 3001 GB STORAGE01 mirror DEGRADED S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 ?C Z1F21TA7 without error short long abort log c15t18d1 3001 GB STORAGE01 mirror DEGRADED S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 ?C Z1F27DCD without error short long abort log c15t19d1 3001 GB STORAGE01 mirror DEGRADED S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 39 ?C Z1F28PSJ without error short long abort log c15t21d1 3001 GB STORAGE01 mirror DEGRADED S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 35 ?C Z1F21NPM without error short long abort log c15t22d1 3001 GB STORAGE01 mirror DEGRADED S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 38 ?C Z1F27CFV without error short long abort log c15t23d1 3001 GB STORAGE01 mirror DEGRADED S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 ?C Z1F27EHT without error short long abort log c15t24d1 3001 GB STORAGE01 mirror DEGRADED S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 ?C Z1F27796 without error short long abort log c15t35d1 3001 GB STORAGE01 mirror DEGRADED S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 25 ?C Z1F27E4X without error short long abort log HD Info: smartctl 6.0 2012-10-10 r3643 [i386-pc-solaris2.11] (local build) Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.14 (AF) Device Model: ST3000DM001-1CH166 Serial Number: Z1F21TA7 LU WWN Device Id: 5 000c50 04f6f0c73 Firmware Version: CC24 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 7200 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Mon Jul 1 16:56:42 2013 BRT Can anyone help me? Thanks. Daniel From skiselkov.ml at gmail.com Mon Jul 1 20:15:48 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 01 Jul 2013 21:15:48 +0100 Subject: [OmniOS-discuss] ZFS Checksum problem In-Reply-To: <51D1DFC5.9090504@dgnetwork.com.br> References: <51D1DFC5.9090504@dgnetwork.com.br> Message-ID: <51D1E374.5090602@gmail.com> On 01/07/2013 21:00, "Daniel D. Gon?alves" wrote: > I'm having trouble checksum in my ZFS pool, I tried to change data > cables and power of HDDs, but the problems remain. > All 8 HDDs that are exhibiting errors are identicaland all is on the > same controller. > > NAME STATE READ WRITE CKSUM > STORAGE01 DEGRADED 0 0 347 > mirror-0 DEGRADED 0 0 188 > c15t35d1 DEGRADED 0 0 188 too many errors > c15t18d1 DEGRADED 0 0 188 too many errors > mirror-1 DEGRADED 0 0 170 > c15t21d1 DEGRADED 0 0 170 too many errors > c15t22d1 DEGRADED 0 0 170 too many errors > mirror-2 DEGRADED 0 0 164 > c15t17d1 DEGRADED 0 0 164 too many errors > c15t19d1 DEGRADED 0 0 164 too many errors > mirror-3 DEGRADED 0 0 172 > c15t24d1 DEGRADED 0 0 172 too many errors > c15t23d1 DEGRADED 0 0 172 too many errors > mirror-5 ONLINE 0 0 0 > c15t25d1 ONLINE 0 0 0 > c15t27d1 ONLINE 0 0 0 > mirror-6 ONLINE 0 0 0 > c15t26d1 ONLINE 0 0 0 > c15t28d1 ONLINE 0 0 0 > mirror-7 ONLINE 0 0 0 > c15t29d1 ONLINE 0 0 0 > c15t31d1 ONLINE 0 0 0 > mirror-8 ONLINE 0 0 0 > c15t32d1 ONLINE 0 0 0 > c15t30d1 ONLINE 0 0 0 > logs > mirror-4 ONLINE 0 0 0 > c14t1d0 ONLINE 0 0 0 > c14t3d0 ONLINE 0 0 0 > cache > c14t4d0 ONLINE 0 0 0 > > Smartinfo: > > c15t17d1 3001 GB STORAGE01 mirror DEGRADED > S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 > ?C Z1F21TA7 without error short long abort log > c15t18d1 3001 GB STORAGE01 mirror DEGRADED > S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 > ?C Z1F27DCD without error short long abort log > c15t19d1 3001 GB STORAGE01 mirror DEGRADED > S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 39 > ?C Z1F28PSJ without error short long abort log > c15t21d1 3001 GB STORAGE01 mirror DEGRADED > S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 35 > ?C Z1F21NPM without error short long abort log > c15t22d1 3001 GB STORAGE01 mirror DEGRADED > S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 38 > ?C Z1F27CFV without error short long abort log > c15t23d1 3001 GB STORAGE01 mirror DEGRADED > S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 > ?C Z1F27EHT without error short long abort log > c15t24d1 3001 GB STORAGE01 mirror DEGRADED > S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 > ?C Z1F27796 without error short long abort log > c15t35d1 3001 GB STORAGE01 mirror DEGRADED > S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 25 > ?C Z1F27E4X without error short long abort log > > HD Info: > > smartctl 6.0 2012-10-10 r3643 [i386-pc-solaris2.11] (local build) > Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF INFORMATION SECTION === > Model Family: Seagate Barracuda 7200.14 (AF) > Device Model: ST3000DM001-1CH166 > Serial Number: Z1F21TA7 > LU WWN Device Id: 5 000c50 04f6f0c73 > Firmware Version: CC24 > User Capacity: 3,000,592,982,016 bytes [3.00 TB] > Sector Sizes: 512 bytes logical, 4096 bytes physical > Rotation Rate: 7200 rpm > Device is: In smartctl database [for details use: -P show] > ATA Version is: ATA8-ACS T13/1699-D revision 4 > SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) > Local Time is: Mon Jul 1 16:56:42 2013 BRT > > Can anyone help me? Try iostat -Exn and have a look at "fmadm faulty" to see if you can pinpoint the fault source. Cheers, -- Saso From daniel at dgnetwork.com.br Mon Jul 1 20:28:00 2013 From: daniel at dgnetwork.com.br (=?ISO-8859-1?Q?=22Daniel_D=2E_Gon=E7alves=22?=) Date: Mon, 01 Jul 2013 17:28:00 -0300 Subject: [OmniOS-discuss] ZFS Checksum problem In-Reply-To: <51D1E374.5090602@gmail.com> References: <51D1DFC5.9090504@dgnetwork.com.br> <51D1E374.5090602@gmail.com> Message-ID: <51D1E650.2040000@dgnetwork.com.br> iostat -Exn result: c15t35d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: Z1F27E4X Size: 3000.59GB <3000592982016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 Illegal Request: 0 Predictive Failure Analysis: 0 c15t18d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: Z1F27DCD Size: 3000.59GB <3000592982016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 Illegal Request: 0 Predictive Failure Analysis: 0 c15t21d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: Z1F21NPM Size: 3000.59GB <3000592982016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 Illegal Request: 0 Predictive Failure Analysis: 0 c15t22d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: Z1F27CFV Size: 3000.59GB <3000592982016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 Illegal Request: 0 Predictive Failure Analysis: 0 c15t17d1 Soft Errors: 5 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: Z1F21TA7 Size: 3000.59GB <3000592982016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 5 Illegal Request: 0 Predictive Failure Analysis: 0 c15t19d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: Z1F28PSJ Size: 3000.59GB <3000592982016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 Illegal Request: 0 Predictive Failure Analysis: 0 c15t23d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: Z1F27EHT Size: 3000.59GB <3000592982016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 Illegal Request: 0 Predictive Failure Analysis: 0 c15t24d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: Z1F27796 Size: 3000.59GB <3000592982016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 Illegal Request: 0 Predictive Failure Analysis: 0 fmadm faulty result: --------------- ------------------------------------ -------------- --------- TIME EVENT-ID MSG-ID SEVERITY --------------- ------------------------------------ -------------- --------- Jun 29 14:48:38 09217f5b-2ded-e74c-bef3-fbaec52391ed ZFS-8000-GH Major Host : storage01 Platform : SandyBridge-Platform Chassis_id : To-be-filled-by-O.E.M. Product_sn : Fault class : fault.fs.zfs.vdev.checksum Affects : zfs://pool=STORAGE01/vdev=40200696be7be968 faulted but still in service Problem in : zfs://pool=STORAGE01/vdev=40200696be7be968 faulted but still in service Description : The number of checksum errors associated with a ZFS device exceeded acceptable levels. Refer to http://illumos.org/msg/ZFS-8000-GH for more information. Response : The device has been marked as degraded. An attempt will be made to activate a hot spare if available. Impact : Fault tolerance of the pool may be compromised. Action : Run 'zpool status -x' and replace the bad device. Already ran the SCRUB several times, but checksum errors occur again, only this 8 HDDs. Remembering, SATA and power cables have been swapped. Daniel Em 01/07/2013 17:15, Saso Kiselkov escreveu: > On 01/07/2013 21:00, "Daniel D. Gon?alves" wrote: >> I'm having trouble checksum in my ZFS pool, I tried to change data >> cables and power of HDDs, but the problems remain. >> All 8 HDDs that are exhibiting errors are identicaland all is on the >> same controller. >> >> NAME STATE READ WRITE CKSUM >> STORAGE01 DEGRADED 0 0 347 >> mirror-0 DEGRADED 0 0 188 >> c15t35d1 DEGRADED 0 0 188 too many errors >> c15t18d1 DEGRADED 0 0 188 too many errors >> mirror-1 DEGRADED 0 0 170 >> c15t21d1 DEGRADED 0 0 170 too many errors >> c15t22d1 DEGRADED 0 0 170 too many errors >> mirror-2 DEGRADED 0 0 164 >> c15t17d1 DEGRADED 0 0 164 too many errors >> c15t19d1 DEGRADED 0 0 164 too many errors >> mirror-3 DEGRADED 0 0 172 >> c15t24d1 DEGRADED 0 0 172 too many errors >> c15t23d1 DEGRADED 0 0 172 too many errors >> mirror-5 ONLINE 0 0 0 >> c15t25d1 ONLINE 0 0 0 >> c15t27d1 ONLINE 0 0 0 >> mirror-6 ONLINE 0 0 0 >> c15t26d1 ONLINE 0 0 0 >> c15t28d1 ONLINE 0 0 0 >> mirror-7 ONLINE 0 0 0 >> c15t29d1 ONLINE 0 0 0 >> c15t31d1 ONLINE 0 0 0 >> mirror-8 ONLINE 0 0 0 >> c15t32d1 ONLINE 0 0 0 >> c15t30d1 ONLINE 0 0 0 >> logs >> mirror-4 ONLINE 0 0 0 >> c14t1d0 ONLINE 0 0 0 >> c14t3d0 ONLINE 0 0 0 >> cache >> c14t4d0 ONLINE 0 0 0 >> >> Smartinfo: >> >> c15t17d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 >> ?C Z1F21TA7 without error short long abort log >> c15t18d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 >> ?C Z1F27DCD without error short long abort log >> c15t19d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 39 >> ?C Z1F28PSJ without error short long abort log >> c15t21d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 35 >> ?C Z1F21NPM without error short long abort log >> c15t22d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 38 >> ?C Z1F27CFV without error short long abort log >> c15t23d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 >> ?C Z1F27EHT without error short long abort log >> c15t24d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 >> ?C Z1F27796 without error short long abort log >> c15t35d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 25 >> ?C Z1F27E4X without error short long abort log >> >> HD Info: >> >> smartctl 6.0 2012-10-10 r3643 [i386-pc-solaris2.11] (local build) >> Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org >> >> === START OF INFORMATION SECTION === >> Model Family: Seagate Barracuda 7200.14 (AF) >> Device Model: ST3000DM001-1CH166 >> Serial Number: Z1F21TA7 >> LU WWN Device Id: 5 000c50 04f6f0c73 >> Firmware Version: CC24 >> User Capacity: 3,000,592,982,016 bytes [3.00 TB] >> Sector Sizes: 512 bytes logical, 4096 bytes physical >> Rotation Rate: 7200 rpm >> Device is: In smartctl database [for details use: -P show] >> ATA Version is: ATA8-ACS T13/1699-D revision 4 >> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) >> Local Time is: Mon Jul 1 16:56:42 2013 BRT >> >> Can anyone help me? > Try iostat -Exn and have a look at "fmadm faulty" to see if you can > pinpoint the fault source. > > Cheers, From skiselkov.ml at gmail.com Mon Jul 1 20:35:19 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 01 Jul 2013 21:35:19 +0100 Subject: [OmniOS-discuss] ZFS Checksum problem In-Reply-To: <51D1E650.2040000@dgnetwork.com.br> References: <51D1DFC5.9090504@dgnetwork.com.br> <51D1E374.5090602@gmail.com> <51D1E650.2040000@dgnetwork.com.br> Message-ID: <51D1E807.3010802@gmail.com> It looks like your controller is faulty and is corrupting data. The drives look fine, all of your errors are on the transport, not on the platters. Try swapping out the controller or move the drives to another controller. Cheers, -- Saso On 01/07/2013 21:28, "Daniel D. Gon?alves" wrote: > iostat -Exn result: > > c15t35d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: > Z1F27E4X > Size: 3000.59GB <3000592982016 bytes> > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 > Illegal Request: 0 Predictive Failure Analysis: 0 > c15t18d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: > Z1F27DCD > Size: 3000.59GB <3000592982016 bytes> > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 > Illegal Request: 0 Predictive Failure Analysis: 0 > > c15t21d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: > Z1F21NPM > Size: 3000.59GB <3000592982016 bytes> > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 > Illegal Request: 0 Predictive Failure Analysis: 0 > c15t22d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: > Z1F27CFV > Size: 3000.59GB <3000592982016 bytes> > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 > Illegal Request: 0 Predictive Failure Analysis: 0 > > c15t17d1 Soft Errors: 5 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: > Z1F21TA7 > Size: 3000.59GB <3000592982016 bytes> > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 5 > Illegal Request: 0 Predictive Failure Analysis: 0 > c15t19d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: > Z1F28PSJ > Size: 3000.59GB <3000592982016 bytes> > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 > Illegal Request: 0 Predictive Failure Analysis: 0 > > c15t23d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: > Z1F27EHT > Size: 3000.59GB <3000592982016 bytes> > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 > Illegal Request: 0 Predictive Failure Analysis: 0 > c15t24d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: > Z1F27796 > Size: 3000.59GB <3000592982016 bytes> > Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 4 > Illegal Request: 0 Predictive Failure Analysis: 0 > > > fmadm faulty result: > > --------------- ------------------------------------ -------------- > --------- > TIME EVENT-ID MSG-ID SEVERITY > --------------- ------------------------------------ -------------- > --------- > Jun 29 14:48:38 09217f5b-2ded-e74c-bef3-fbaec52391ed ZFS-8000-GH Major > > Host : storage01 > Platform : SandyBridge-Platform Chassis_id : > To-be-filled-by-O.E.M. > Product_sn : > > Fault class : fault.fs.zfs.vdev.checksum > Affects : zfs://pool=STORAGE01/vdev=40200696be7be968 > faulted but still in service > Problem in : zfs://pool=STORAGE01/vdev=40200696be7be968 > faulted but still in service > > Description : The number of checksum errors associated with a ZFS device > exceeded acceptable levels. Refer to > http://illumos.org/msg/ZFS-8000-GH for more information. > > Response : The device has been marked as degraded. An attempt > will be made to activate a hot spare if available. > > Impact : Fault tolerance of the pool may be compromised. > > Action : Run 'zpool status -x' and replace the bad device. > > > Already ran the SCRUB several times, but checksum errors occur again, > only this 8 HDDs. > Remembering, SATA and power cables have been swapped. > > Daniel > > Em 01/07/2013 17:15, Saso Kiselkov escreveu: >> On 01/07/2013 21:00, "Daniel D. Gon?alves" wrote: >>> I'm having trouble checksum in my ZFS pool, I tried to change data >>> cables and power of HDDs, but the problems remain. >>> All 8 HDDs that are exhibiting errors are identicaland all is on the >>> same controller. >>> >>> NAME STATE READ WRITE CKSUM >>> STORAGE01 DEGRADED 0 0 347 >>> mirror-0 DEGRADED 0 0 188 >>> c15t35d1 DEGRADED 0 0 188 too many errors >>> c15t18d1 DEGRADED 0 0 188 too many errors >>> mirror-1 DEGRADED 0 0 170 >>> c15t21d1 DEGRADED 0 0 170 too many errors >>> c15t22d1 DEGRADED 0 0 170 too many errors >>> mirror-2 DEGRADED 0 0 164 >>> c15t17d1 DEGRADED 0 0 164 too many errors >>> c15t19d1 DEGRADED 0 0 164 too many errors >>> mirror-3 DEGRADED 0 0 172 >>> c15t24d1 DEGRADED 0 0 172 too many errors >>> c15t23d1 DEGRADED 0 0 172 too many errors >>> mirror-5 ONLINE 0 0 0 >>> c15t25d1 ONLINE 0 0 0 >>> c15t27d1 ONLINE 0 0 0 >>> mirror-6 ONLINE 0 0 0 >>> c15t26d1 ONLINE 0 0 0 >>> c15t28d1 ONLINE 0 0 0 >>> mirror-7 ONLINE 0 0 0 >>> c15t29d1 ONLINE 0 0 0 >>> c15t31d1 ONLINE 0 0 0 >>> mirror-8 ONLINE 0 0 0 >>> c15t32d1 ONLINE 0 0 0 >>> c15t30d1 ONLINE 0 0 0 >>> logs >>> mirror-4 ONLINE 0 0 0 >>> c14t1d0 ONLINE 0 0 0 >>> c14t3d0 ONLINE 0 0 0 >>> cache >>> c14t4d0 ONLINE 0 0 0 >>> >>> Smartinfo: >>> >>> c15t17d1 3001 GB STORAGE01 mirror DEGRADED >>> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 >>> ?C Z1F21TA7 without error short long abort log >>> c15t18d1 3001 GB STORAGE01 mirror DEGRADED >>> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 >>> ?C Z1F27DCD without error short long abort log >>> c15t19d1 3001 GB STORAGE01 mirror DEGRADED >>> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 39 >>> ?C Z1F28PSJ without error short long abort log >>> c15t21d1 3001 GB STORAGE01 mirror DEGRADED >>> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 35 >>> ?C Z1F21NPM without error short long abort log >>> c15t22d1 3001 GB STORAGE01 mirror DEGRADED >>> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 38 >>> ?C Z1F27CFV without error short long abort log >>> c15t23d1 3001 GB STORAGE01 mirror DEGRADED >>> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 >>> ?C Z1F27EHT without error short long abort log >>> c15t24d1 3001 GB STORAGE01 mirror DEGRADED >>> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 >>> ?C Z1F27796 without error short long abort log >>> c15t35d1 3001 GB STORAGE01 mirror DEGRADED >>> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 25 >>> ?C Z1F27E4X without error short long abort log >>> >>> HD Info: >>> >>> smartctl 6.0 2012-10-10 r3643 [i386-pc-solaris2.11] (local build) >>> Copyright (C) 2002-12, Bruce Allen, Christian Franke, >>> www.smartmontools.org >>> >>> === START OF INFORMATION SECTION === >>> Model Family: Seagate Barracuda 7200.14 (AF) >>> Device Model: ST3000DM001-1CH166 >>> Serial Number: Z1F21TA7 >>> LU WWN Device Id: 5 000c50 04f6f0c73 >>> Firmware Version: CC24 >>> User Capacity: 3,000,592,982,016 bytes [3.00 TB] >>> Sector Sizes: 512 bytes logical, 4096 bytes physical >>> Rotation Rate: 7200 rpm >>> Device is: In smartctl database [for details use: -P show] >>> ATA Version is: ATA8-ACS T13/1699-D revision 4 >>> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) >>> Local Time is: Mon Jul 1 16:56:42 2013 BRT >>> >>> Can anyone help me? >> Try iostat -Exn and have a look at "fmadm faulty" to see if you can >> pinpoint the fault source. >> >> Cheers, > From esproul at omniti.com Mon Jul 1 20:38:08 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 1 Jul 2013 16:38:08 -0400 Subject: [OmniOS-discuss] ZFS Checksum problem In-Reply-To: <51D1E650.2040000@dgnetwork.com.br> References: <51D1DFC5.9090504@dgnetwork.com.br> <51D1E374.5090602@gmail.com> <51D1E650.2040000@dgnetwork.com.br> Message-ID: On Mon, Jul 1, 2013 at 4:28 PM, "Daniel D. Gon?alves" wrote: > iostat -Exn result: > > c15t35d1 Soft Errors: 4 Hard Errors: 0 Transport Errors: 0 > Vendor: ATA Product: ST3000DM001-1CH1 Revision: CC24 Serial No: These are desktop-class drives and are probably having trouble with vibration, being installed with so many spindles in the same chassis. I've seen similar problems, but after replacing the drives with "enterprise", aka "near-line" 7200 rpm drives, there have been no more crazy checksum issues. Are the other (non-checksum-erroring) drives the same make and model, or similarly not designed for datacenter use? Eric From daniel at dgnetwork.com.br Mon Jul 1 20:53:12 2013 From: daniel at dgnetwork.com.br (=?ISO-8859-1?Q?=22Daniel_D=2E_Gon=E7alves=22?=) Date: Mon, 01 Jul 2013 17:53:12 -0300 Subject: [OmniOS-discuss] ZFS Checksum problem In-Reply-To: References: <51D1DFC5.9090504@dgnetwork.com.br> <51D1E374.5090602@gmail.com> <51D1E650.2040000@dgnetwork.com.br> Message-ID: <51D1EC38.3050606@dgnetwork.com.br> The other drives are the same model (desktop class), but some are model ST3000DM001-1CH166 and other model ST3000DM001-9YN166. The firmware of some are different, the hard drives that are in trouble are firmware CC24, while others are CC4B and CC26. Swap the drives for Enterprise model are out of the question now. Any suggestions? Em 01/07/2013 17:38, Eric Sproul escreveu: > These are desktop-class drives and are probably having trouble with > vibration, being installed with so many spindles in the same chassis. > I've seen similar problems, but after replacing the drives with > "enterprise", aka "near-line" 7200 rpm drives, there have been no more > crazy checksum issues. > > Are the other (non-checksum-erroring) drives the same make and model, > or similarly not designed for datacenter use? > > Eric From esproul at omniti.com Mon Jul 1 21:05:53 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 1 Jul 2013 17:05:53 -0400 Subject: [OmniOS-discuss] ZFS Checksum problem In-Reply-To: <51D1EC38.3050606@dgnetwork.com.br> References: <51D1DFC5.9090504@dgnetwork.com.br> <51D1E374.5090602@gmail.com> <51D1E650.2040000@dgnetwork.com.br> <51D1EC38.3050606@dgnetwork.com.br> Message-ID: On Mon, Jul 1, 2013 at 4:53 PM, "Daniel D. Gon?alves" wrote: > The other drives are the same model (desktop class), but some are model > ST3000DM001-1CH166 and other model ST3000DM001-9YN166. > The firmware of some are different, the hard drives that are in trouble are > firmware CC24, while others are CC4B and CC26. > > Swap the drives for Enterprise model are out of the question now. Any > suggestions? If you suspect firmware, you could try upgrading one of the "bad" drives and see if the cksum errors stop. You could try detaching one drive from each controller (i.e. one "good" and one "bad") and attaching them to the other. That might indicate whether the problem follows the controller or the drive. Eric From richard.elling at richardelling.com Mon Jul 1 21:27:48 2013 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 1 Jul 2013 14:27:48 -0700 Subject: [OmniOS-discuss] ZFS Checksum problem In-Reply-To: <51D1E374.5090602@gmail.com> References: <51D1DFC5.9090504@dgnetwork.com.br> <51D1E374.5090602@gmail.com> Message-ID: troubleshooting tips below... On Jul 1, 2013, at 1:15 PM, Saso Kiselkov wrote: > On 01/07/2013 21:00, "Daniel D. Gon?alves" wrote: >> I'm having trouble checksum in my ZFS pool, I tried to change data >> cables and power of HDDs, but the problems remain. >> All 8 HDDs that are exhibiting errors are identicaland all is on the >> same controller. >> >> NAME STATE READ WRITE CKSUM >> STORAGE01 DEGRADED 0 0 347 >> mirror-0 DEGRADED 0 0 188 >> c15t35d1 DEGRADED 0 0 188 too many errors >> c15t18d1 DEGRADED 0 0 188 too many errors >> mirror-1 DEGRADED 0 0 170 >> c15t21d1 DEGRADED 0 0 170 too many errors >> c15t22d1 DEGRADED 0 0 170 too many errors >> mirror-2 DEGRADED 0 0 164 >> c15t17d1 DEGRADED 0 0 164 too many errors >> c15t19d1 DEGRADED 0 0 164 too many errors >> mirror-3 DEGRADED 0 0 172 >> c15t24d1 DEGRADED 0 0 172 too many errors >> c15t23d1 DEGRADED 0 0 172 too many errors smells like a bad cable, power supply, expander, or controller... >> mirror-5 ONLINE 0 0 0 >> c15t25d1 ONLINE 0 0 0 >> c15t27d1 ONLINE 0 0 0 >> mirror-6 ONLINE 0 0 0 >> c15t26d1 ONLINE 0 0 0 >> c15t28d1 ONLINE 0 0 0 >> mirror-7 ONLINE 0 0 0 >> c15t29d1 ONLINE 0 0 0 >> c15t31d1 ONLINE 0 0 0 >> mirror-8 ONLINE 0 0 0 >> c15t32d1 ONLINE 0 0 0 >> c15t30d1 ONLINE 0 0 0 >> logs >> mirror-4 ONLINE 0 0 0 >> c14t1d0 ONLINE 0 0 0 >> c14t3d0 ONLINE 0 0 0 >> cache >> c14t4d0 ONLINE 0 0 0 >> >> Smartinfo: >> >> c15t17d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 >> ?C Z1F21TA7 without error short long abort log >> c15t18d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 >> ?C Z1F27DCD without error short long abort log >> c15t19d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 39 >> ?C Z1F28PSJ without error short long abort log >> c15t21d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 35 >> ?C Z1F21NPM without error short long abort log >> c15t22d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 38 >> ?C Z1F27CFV without error short long abort log >> c15t23d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 40 >> ?C Z1F27EHT without error short long abort log >> c15t24d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 41 >> ?C Z1F27796 without error short long abort log >> c15t35d1 3001 GB STORAGE01 mirror DEGRADED >> S:4 H:0 T:0 ST3000DM001-1CH166 sat,12 PASSED 25 >> ?C Z1F27E4X without error short long abort log disks look clean >> >> HD Info: >> >> smartctl 6.0 2012-10-10 r3643 [i386-pc-solaris2.11] (local build) >> Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org >> >> === START OF INFORMATION SECTION === >> Model Family: Seagate Barracuda 7200.14 (AF) >> Device Model: ST3000DM001-1CH166 >> Serial Number: Z1F21TA7 >> LU WWN Device Id: 5 000c50 04f6f0c73 >> Firmware Version: CC24 >> User Capacity: 3,000,592,982,016 bytes [3.00 TB] >> Sector Sizes: 512 bytes logical, 4096 bytes physical >> Rotation Rate: 7200 rpm >> Device is: In smartctl database [for details use: -P show] >> ATA Version is: ATA8-ACS T13/1699-D revision 4 >> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) >> Local Time is: Mon Jul 1 16:56:42 2013 BRT >> >> Can anyone help me? > > Try iostat -Exn and have a look at "fmadm faulty" to see if you can > pinpoint the fault source. fmdump -e shows the error reports. These are more interesting than the faulty diagnosis in this case. If the only error reports you see are ZFS checksums, then it is more difficult to get to root cause, because that means something in the datapath is corrupting data. If you see other errors, like transport or data errors, then it will be a better clue. -- richard > > Cheers, > -- > Saso > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at smidsrod.no Tue Jul 2 08:57:38 2013 From: robin at smidsrod.no (=?UTF-8?B?Um9iaW4gU21pZHNyw7hk?=) Date: Tue, 02 Jul 2013 10:57:38 +0200 Subject: [OmniOS-discuss] Marvell 88SE9128 AHCI/SATA3 driver support added Message-ID: <51D29602.8010702@smidsrod.no> Any chance of these changes to illumos-gate required for supporting Marvell 88SE9128 will end up in current stable, or are they expected in the next stable release? https://www.illumos.org/issues/993 https://www.illumos.org/issues/3797 https://www.illumos.org/issues/3815 It doesn't seem like the bug history clearly states if this controller is expected to work reliably or not from now on. Could someone clarify? Unsure if I should dare to connect anything to that controller or not (once the fixes become part of stable). -- Robin From esproul at omniti.com Tue Jul 2 13:57:26 2013 From: esproul at omniti.com (Eric Sproul) Date: Tue, 2 Jul 2013 09:57:26 -0400 Subject: [OmniOS-discuss] Marvell 88SE9128 AHCI/SATA3 driver support added In-Reply-To: <51D29602.8010702@smidsrod.no> References: <51D29602.8010702@smidsrod.no> Message-ID: Robin, These changes will likely remain in bloody and become part of r151008. The changeset for 3797 is in illumos-omnios and there should be packages for bloody coming soon that include this code. The one for 3815 doesn't look like it's been merged yet into illumos-omnios. Eric On Tue, Jul 2, 2013 at 4:57 AM, Robin Smidsr?d wrote: > Any chance of these changes to illumos-gate required for supporting > Marvell 88SE9128 will end up in current stable, or are they expected in > the next stable release? > > https://www.illumos.org/issues/993 > https://www.illumos.org/issues/3797 > https://www.illumos.org/issues/3815 > > It doesn't seem like the bug history clearly states if this controller > is expected to work reliably or not from now on. Could someone clarify? > > Unsure if I should dare to connect anything to that controller or not > (once the fixes become part of stable). > > -- Robin > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From esproul at omniti.com Tue Jul 2 15:46:35 2013 From: esproul at omniti.com (Eric Sproul) Date: Tue, 2 Jul 2013 11:46:35 -0400 Subject: [OmniOS-discuss] New wiki page explains OmniOS release cycle Message-ID: FYI, I've just added a new wiki page detailing the OmniOS release cycle: http://omnios.omniti.com/wiki.php/ReleaseCycle We release a new stable every 26 weeks, with weekly interim updates as needed. Starting with the current stable release (r151006), some stable releases are designated "Long-Tail Support" and will receive updates for three years. Normal stable releases will receive updates for one year. In the coming months, leading up to the release of r151008, we'll have more information about how to stay on an LTS release. Eric From alex at cooperi.net Wed Jul 3 03:56:57 2013 From: alex at cooperi.net (Alex Wilson) Date: Wed, 3 Jul 2013 13:56:57 +1000 Subject: [OmniOS-discuss] Marvell 88SE9128 AHCI/SATA3 driver support added In-Reply-To: References: <51D29602.8010702@smidsrod.no> Message-ID: On the unsure if you should connect anything front -- I have a kernel I built just after those changes were merged in, with omnios-bloody, and it's running quite well so far. Mine's got 4 disks on it that are part of a 6-disk raidz2 vdev and it's been storing, ahem, non-critical bit torrent data (it's all Linux ISOs, obviously). It's been reading and writing at a few MB/sec for most of the week since then without any problems. That said, none of the disks attached have had any problems as yet -- handling errors is usually where newly supported controllers explode worst. So ymmv, naturally. On a semi-related note, I'm also using the newly added support for the ASMedia ASM106x chips on a couple of machines (all with mSATA SSDs attached, serving as mirrored ZIL/l2arc on quite busy but non-critical hosts) and it's also fine, just not the fastest thing ever (as expected from the price). Most of the changes for both these chips have just been relaxing the ahci code's expectations about the level of standards-compliance of the things it talks to, and some minor modifications for the newer revisions of AHCI. They're probably about as safe as brand new things get. On 02/07/2013, at 11:57 PM, Eric Sproul wrote: > Robin, > These changes will likely remain in bloody and become part of r151008. > The changeset for 3797 is in illumos-omnios and there should be > packages for bloody coming soon that include this code. The one for > 3815 doesn't look like it's been merged yet into illumos-omnios. > > Eric > > On Tue, Jul 2, 2013 at 4:57 AM, Robin Smidsr?d wrote: >> Any chance of these changes to illumos-gate required for supporting >> Marvell 88SE9128 will end up in current stable, or are they expected in >> the next stable release? >> >> https://www.illumos.org/issues/993 >> https://www.illumos.org/issues/3797 >> https://www.illumos.org/issues/3815 >> >> It doesn't seem like the bug history clearly states if this controller >> is expected to work reliably or not from now on. Could someone clarify? >> >> Unsure if I should dare to connect anything to that controller or not >> (once the fixes become part of stable). >> >> -- Robin >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From alex at cooperi.net Wed Jul 3 04:00:01 2013 From: alex at cooperi.net (Alex Wilson) Date: Wed, 3 Jul 2013 14:00:01 +1000 Subject: [OmniOS-discuss] Marvell 88SE9128 AHCI/SATA3 driver support added In-Reply-To: References: <51D29602.8010702@smidsrod.no> Message-ID: <8D64B6B5-C95F-4BA8-A00D-B923EE2D9C81@cooperi.net> Just an addendum, by "merged in" I meant merged into illumos-gate -- I merged them with illumos-omnios myself last week (including the SATA3 patch) and built from that. On 03/07/2013, at 1:56 PM, Alex Wilson wrote: > On the unsure if you should connect anything front -- I have a kernel I built just after those changes were merged in, with omnios-bloody, and it's running quite well so far. Mine's got 4 disks on it that are part of a 6-disk raidz2 vdev and it's been storing, ahem, non-critical bit torrent data (it's all Linux ISOs, obviously). It's been reading and writing at a few MB/sec for most of the week since then without any problems. > > That said, none of the disks attached have had any problems as yet -- handling errors is usually where newly supported controllers explode worst. So ymmv, naturally. > > On a semi-related note, I'm also using the newly added support for the ASMedia ASM106x chips on a couple of machines (all with mSATA SSDs attached, serving as mirrored ZIL/l2arc on quite busy but non-critical hosts) and it's also fine, just not the fastest thing ever (as expected from the price). Most of the changes for both these chips have just been relaxing the ahci code's expectations about the level of standards-compliance of the things it talks to, and some minor modifications for the newer revisions of AHCI. They're probably about as safe as brand new things get. > > > On 02/07/2013, at 11:57 PM, Eric Sproul wrote: > >> Robin, >> These changes will likely remain in bloody and become part of r151008. >> The changeset for 3797 is in illumos-omnios and there should be >> packages for bloody coming soon that include this code. The one for >> 3815 doesn't look like it's been merged yet into illumos-omnios. >> >> Eric >> >> On Tue, Jul 2, 2013 at 4:57 AM, Robin Smidsr?d wrote: >>> Any chance of these changes to illumos-gate required for supporting >>> Marvell 88SE9128 will end up in current stable, or are they expected in >>> the next stable release? >>> >>> https://www.illumos.org/issues/993 >>> https://www.illumos.org/issues/3797 >>> https://www.illumos.org/issues/3815 >>> >>> It doesn't seem like the bug history clearly states if this controller >>> is expected to work reliably or not from now on. Could someone clarify? >>> >>> Unsure if I should dare to connect anything to that controller or not >>> (once the fixes become part of stable). >>> >>> -- Robin >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From robin at smidsrod.no Wed Jul 3 12:52:02 2013 From: robin at smidsrod.no (=?UTF-8?B?Um9iaW4gU21pZHNyw7hk?=) Date: Wed, 03 Jul 2013 14:52:02 +0200 Subject: [OmniOS-discuss] Marvell 88SE9128 AHCI/SATA3 driver support added In-Reply-To: References: <51D29602.8010702@smidsrod.no> Message-ID: <51D41E72.90304@smidsrod.no> On 03.07.2013 05:56, Alex Wilson wrote: > On the unsure if you should connect anything front -- I have a kernel I built just after those changes were merged in, with omnios-bloody, and it's running quite well so far. Mine's got 4 disks on it that are part of a 6-disk raidz2 vdev and it's been storing, ahem, non-critical bit torrent data (it's all Linux ISOs, obviously). It's been reading and writing at a few MB/sec for most of the week since then without any problems. > > That said, none of the disks attached have had any problems as yet -- handling errors is usually where newly supported controllers explode worst. So ymmv, naturally. > > On a semi-related note, I'm also using the newly added support for the ASMedia ASM106x chips on a couple of machines (all with mSATA SSDs attached, serving as mirrored ZIL/l2arc on quite busy but non-critical hosts) and it's also fine, just not the fastest thing ever (as expected from the price). Most of the changes for both these chips have just been relaxing the ahci code's expectations about the level of standards-compliance of the things it talks to, and some minor modifications for the newer revisions of AHCI. They're probably about as safe as brand new things get. Thanks a bunch for the feedback on the reliability front. Nice to hear that it seems stable (for now). Please do tell if you have a disk problem and it behaves nicely or explode. I guess that at least means I can re-enable that controller once I upgrade to r151008 in some months. I might try to use it for some testing before I dare put anything critical on it (even though it's just a home setup). -- Robin From esproul at omniti.com Wed Jul 3 13:14:35 2013 From: esproul at omniti.com (Eric Sproul) Date: Wed, 3 Jul 2013 09:14:35 -0400 Subject: [OmniOS-discuss] Marvell 88SE9128 AHCI/SATA3 driver support added In-Reply-To: <51D41E72.90304@smidsrod.no> References: <51D29602.8010702@smidsrod.no> <51D41E72.90304@smidsrod.no> Message-ID: On Wed, Jul 3, 2013 at 8:52 AM, Robin Smidsr?d wrote: > I guess that at least means I can re-enable that controller once I > upgrade to r151008 in some months. I might try to use it for some > testing before I dare put anything critical on it (even though it's just > a home setup). Following Robin's initial email yesterday, there was a discussion on #omnios about the release strategy (which also triggered my creating the Release Cycle wiki page), and since r151006 is an LTS release, the changesets affecting the new AHCI code will eventually find their way into r151006. They were merged into illumos-omnios yesterday. It would be great if those, like Alex, willing to try their hardware under bloody, could kick the tires a bit more. Eric From robin at smidsrod.no Wed Jul 3 16:05:31 2013 From: robin at smidsrod.no (=?UTF-8?B?Um9iaW4gU21pZHNyw7hk?=) Date: Wed, 03 Jul 2013 18:05:31 +0200 Subject: [OmniOS-discuss] Marvell 88SE9128 AHCI/SATA3 driver support added In-Reply-To: References: <51D29602.8010702@smidsrod.no> <51D41E72.90304@smidsrod.no> Message-ID: <51D44BCB.8040904@smidsrod.no> On 03.07.2013 15:14, Eric Sproul wrote: > On Wed, Jul 3, 2013 at 8:52 AM, Robin Smidsr?d wrote: >> I guess that at least means I can re-enable that controller once I >> upgrade to r151008 in some months. I might try to use it for some >> testing before I dare put anything critical on it (even though it's just >> a home setup). > > Following Robin's initial email yesterday, there was a discussion on > #omnios about the release strategy (which also triggered my creating > the Release Cycle wiki page), and since r151006 is an LTS release, the > changesets affecting the new AHCI code will eventually find their way > into r151006. That is good to know! I'm not sure if I'll stay on LTS or stable, though. I guess I'll have to make up my mind later. > They were merged into illumos-omnios yesterday. It > would be great if those, like Alex, willing to try their hardware > under bloody, could kick the tires a bit more. The mainboard I have with the 88SE9128 is this one: Gigabyte GA-X58A-UD3R rev 2.0 http://www.gigabyte.com/products/product-page.aspx?pid=3449#ov It's a cheapo board that supports a decent amount of memory and the i-series Intel CPUs with 10 onboard SATA ports. Except for the need to disable the Marvell SATA3 controller in the BIOS, I've been running this hardware stable on Nexenta NCP (and now OmniOS r151006) for a few years. When Firefly (http://sourceforge.net/projects/fireflyfailsafe/) comes out with these patches integrated I guess I could take it out for a spin and see what happens. It is an easier testing ground for a piece of hardware that is "in production" most of the time. I've posted a ticket in their bug tracker to get them included, which should ease testing to some extent. https://sourceforge.net/p/fireflyfailsafe/tickets/1/ -- Robin From daleg at omniti.com Wed Jul 3 21:44:51 2013 From: daleg at omniti.com (Dale Ghent) Date: Wed, 3 Jul 2013 17:44:51 -0400 Subject: [OmniOS-discuss] Updated release: r151006j Message-ID: This week brings a new release: r151006j This release includes a security fix for curl, as well as other bug fixes and minor improvements (you might notice that your net-snmp commands now work :V ) Full release notes are available here: http://omnios.omniti.com/wiki.php/ReleaseNotes#r151006j As this is an update which addresses a security issue, fresh r151006j install media has also been generated: http://omnios.omniti.com/wiki.php/Installation /dale From lists at mcintyreweb.com Thu Jul 4 22:52:54 2013 From: lists at mcintyreweb.com (Hugh McIntyre) Date: Thu, 04 Jul 2013 15:52:54 -0700 Subject: [OmniOS-discuss] Mail server package for OmniOS? Message-ID: <51D5FCC6.6010008@mcintyreweb.com> Just installed an OmniOS server for backups at home, and it looks like there's no mail server in the default package repo. What are other people who need a mail server using? This is only going to be for client-side sending of mail -- only in case cron wants to send mail, i.e. no local mail delivery. Preferably either postfix (because it's used elsewhere here so I have a working config) or sendmail (likewise a working config from previous Solaris systems). Is there another existing pkg repo (Openindiana, or ...?) or are people mostly compiling from source, or doing without? Hugh. From jesus at omniti.com Thu Jul 4 23:01:46 2013 From: jesus at omniti.com (Theo Schlossnagle) Date: Thu, 4 Jul 2013 19:01:46 -0400 Subject: [OmniOS-discuss] Mail server package for OmniOS? In-Reply-To: <51D5FCC6.6010008@mcintyreweb.com> References: <51D5FCC6.6010008@mcintyreweb.com> Message-ID: Sendmail ships with omnios. On Jul 4, 2013 6:56 PM, "Hugh McIntyre" wrote: > > Just installed an OmniOS server for backups at home, and it looks like > there's no mail server in the default package repo. > > What are other people who need a mail server using? This is only going to > be for client-side sending of mail -- only in case cron wants to send mail, > i.e. no local mail delivery. Preferably either postfix (because it's used > elsewhere here so I have a working config) or sendmail (likewise a working > config from previous Solaris systems). > > Is there another existing pkg repo (Openindiana, or ...?) or are people > mostly compiling from source, or doing without? > > Hugh. > > > ______________________________**_________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.**com > http://lists.omniti.com/**mailman/listinfo/omnios-**discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at yonderway.com Thu Jul 4 23:08:27 2013 From: magnus at yonderway.com (Magnus) Date: Thu, 4 Jul 2013 19:08:27 -0400 Subject: [OmniOS-discuss] Mail server package for OmniOS? In-Reply-To: <51D5FCC6.6010008@mcintyreweb.com> References: <51D5FCC6.6010008@mcintyreweb.com> Message-ID: On Jul 4, 2013, at 6:52 PM, Hugh McIntyre wrote: > > Just installed an OmniOS server for backups at home, and it looks like there's no mail server in the default package repo. Out of the box, the packages available are going to be slim pickings. You'll probably want to add at least one popular package publisher. Example: PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/release/ tuna% sudo pkg set-publisher -g http://pkg.omniti.com/omniti-ms/ ms.omniti.com Password: tuna% pkg publisher PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/release/ ms.omniti.com origin online http://pkg.omniti.com/omniti-ms/ tuna% You should be able to install pkg:/service/network/smtp/sendmail for MTA purposes (I don't see a Postfix package out there yet but I haven't searched all available publishers). For IMAP, I see pkg:/omniti/network/dovecot out there. -M From lists at mcintyreweb.com Thu Jul 4 23:45:55 2013 From: lists at mcintyreweb.com (Hugh McIntyre) Date: Thu, 04 Jul 2013 16:45:55 -0700 Subject: [OmniOS-discuss] Mail server package for OmniOS? In-Reply-To: References: <51D5FCC6.6010008@mcintyreweb.com> Message-ID: <51D60933.6040407@mcintyreweb.com> Hmm. Thanks for the quick reply. I admit I was surprised to not find it at first, but for some reason didn't see a match with "pkg search mail". Anyway, thanks for the replies. Hugh. On 7/4/13 4:01 PM, Theo Schlossnagle wrote: > Sendmail ships with omnios. > On Jul 4, 2013 6:56 PM, "Hugh McIntyre" wrote: > >> >> Just installed an OmniOS server for backups at home, and it looks like >> there's no mail server in the default package repo. >> >> What are other people who need a mail server using? This is only going to >> be for client-side sending of mail -- only in case cron wants to send mail, >> i.e. no local mail delivery. Preferably either postfix (because it's used >> elsewhere here so I have a working config) or sendmail (likewise a working >> config from previous Solaris systems). >> >> Is there another existing pkg repo (Openindiana, or ...?) or are people >> mostly compiling from source, or doing without? >> >> Hugh. >> >> >> ______________________________**_________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.**com >> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss >> > From alka at hfg-gmuend.de Fri Jul 5 06:59:34 2013 From: alka at hfg-gmuend.de (Guenther Alka) Date: Fri, 05 Jul 2013 08:59:34 +0200 Subject: [OmniOS-discuss] Mail server package for OmniOS? In-Reply-To: <51D60933.6040407@mcintyreweb.com> References: <51D5FCC6.6010008@mcintyreweb.com> <51D60933.6040407@mcintyreweb.com> Message-ID: <51D66ED6.8070007@hfg-gmuend.de> check http://omnios.omniti.com/wiki.php/Packaging for repos, especially http://scott.mathematik.uni-ulm.de/ with goodies like dovecot, postfix, netatalk, samba4,.. http://scott.mathematik.uni-ulm.de/release/en/catalog.shtml Gea Am 05.07.2013 01:45, schrieb Hugh McIntyre: > Hmm. Thanks for the quick reply. > > I admit I was surprised to not find it at first, but for some reason > didn't see a match with "pkg search mail". > > Anyway, thanks for the replies. > > Hugh. > > > > On 7/4/13 4:01 PM, Theo Schlossnagle wrote: >> Sendmail ships with omnios. >> On Jul 4, 2013 6:56 PM, "Hugh McIntyre" wrote: >> >>> >>> Just installed an OmniOS server for backups at home, and it looks like >>> there's no mail server in the default package repo. >>> >>> What are other people who need a mail server using? This is only >>> going to >>> be for client-side sending of mail -- only in case cron wants to >>> send mail, >>> i.e. no local mail delivery. Preferably either postfix (because >>> it's used >>> elsewhere here so I have a working config) or sendmail (likewise a >>> working >>> config from previous Solaris systems). >>> >>> Is there another existing pkg repo (Openindiana, or ...?) or are people >>> mostly compiling from source, or doing without? >>> >>> Hugh. >>> >>> >>> ______________________________**_________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.**com >>> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss >>> >>> >> > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From sk at kram.io Fri Jul 5 08:39:54 2013 From: sk at kram.io (Steffen Kram) Date: Fri, 5 Jul 2013 10:39:54 +0200 Subject: [OmniOS-discuss] Mail server package for OmniOS? In-Reply-To: <51D66ED6.8070007@hfg-gmuend.de> References: <51D5FCC6.6010008@mcintyreweb.com> <51D60933.6040407@mcintyreweb.com> <51D66ED6.8070007@hfg-gmuend.de> Message-ID: As maintainer of uulm.mawi I just want to add ? the provided postfix does work and is tested for standard tasks. I'm experimenting with a postfix-dovecot-ldap config, but I guarantee for nothing. If you've got suggestions for improvements, please submit an issue on github. That said, you can safely use the provided postfix for a home-server to deliver local mails. Theres one problem in using postfix over the provided sendmail. Some core packages depend on a sendmail installation e.g. smtp-notify. In this case I also provide a modified version (changed sendmail dependency to optional) for smtp-notify but I'm not quite satisfied that I have to repackage such basic system packages to throw out sendmail dependencies. Maybe, it would be possible to enable such packages to be used with other mta-implementations. It's not a problem on servers that do not run a mta ? but if you run postfix anyway, you do not want an additional sendmail, but you may want things like smtp-notify for your hardware/system errors. Cheers, Steffen Am 05.07.2013 um 08:59 schrieb Guenther Alka : > check http://omnios.omniti.com/wiki.php/Packaging for repos, > especially http://scott.mathematik.uni-ulm.de/ > > with goodies like dovecot, postfix, netatalk, samba4,.. > http://scott.mathematik.uni-ulm.de/release/en/catalog.shtml > > Gea > > Am 05.07.2013 01:45, schrieb Hugh McIntyre: >> Hmm. Thanks for the quick reply. >> >> I admit I was surprised to not find it at first, but for some reason didn't see a match with "pkg search mail". >> >> Anyway, thanks for the replies. >> >> Hugh. >> >> >> >> On 7/4/13 4:01 PM, Theo Schlossnagle wrote: >>> Sendmail ships with omnios. >>> On Jul 4, 2013 6:56 PM, "Hugh McIntyre" wrote: >>> >>>> >>>> Just installed an OmniOS server for backups at home, and it looks like >>>> there's no mail server in the default package repo. >>>> >>>> What are other people who need a mail server using? This is only going to >>>> be for client-side sending of mail -- only in case cron wants to send mail, >>>> i.e. no local mail delivery. Preferably either postfix (because it's used >>>> elsewhere here so I have a working config) or sendmail (likewise a working >>>> config from previous Solaris systems). >>>> >>>> Is there another existing pkg repo (Openindiana, or ...?) or are people >>>> mostly compiling from source, or doing without? >>>> >>>> Hugh. >>>> >>>> >>>> ______________________________**_________________ >>>> OmniOS-discuss mailing list >>>> OmniOS-discuss at lists.omniti.**com >>>> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss >>>> >>> >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From lotheac at iki.fi Fri Jul 5 09:00:07 2013 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Fri, 5 Jul 2013 12:00:07 +0300 Subject: [OmniOS-discuss] Mail server package for OmniOS? In-Reply-To: References: <51D5FCC6.6010008@mcintyreweb.com> <51D60933.6040407@mcintyreweb.com> <51D66ED6.8070007@hfg-gmuend.de> Message-ID: <20130705090007.GD9006@niksula.hut.fi> On Fri, Jul 05 2013 10:39:54 +0200, Steffen Kram wrote: > Theres one problem in using postfix over the provided sendmail. Some > core packages depend on a sendmail installation e.g. smtp-notify. In > this case I also provide a modified version (changed sendmail > dependency to optional) for smtp-notify but I'm not quite satisfied > that I have to repackage such basic system packages to throw out > sendmail dependencies. > > Maybe, it would be possible to enable such packages to be used with > other mta-implementations. It's not a problem on servers that do not > run a mta ? but if you run postfix anyway, you do not want an > additional sendmail, but you may want things like smtp-notify for your > hardware/system errors. I'd like to see this as well. I package postfix myself (because I want to use /usr prefix for packaged software :), but I can't install it at the same time as sendmail since both ship a 'sendmail' binary. IPS has mediations that can solve the problem, but I don't know if you can make packages depend on a mediation; that would allow choosing other MTA implementations (provided that sendmail then also participated in the mediation). -- Lauri Tirkkonen From sk at kram.io Mon Jul 8 09:00:02 2013 From: sk at kram.io (Steffen Kram) Date: Mon, 8 Jul 2013 11:00:02 +0200 Subject: [OmniOS-discuss] IPMI on Dell R720 In-Reply-To: References: Message-ID: <9DC398E6-DB7A-4BB3-9DBD-296BAB26CE79@kram.io> Hi, I just ran into the same problem with the ipmi on a Supermicro X9SCM-F and had to rebuild the ipmitool package. I think the real problem is, that the omnios build.sh does not declare a dependency for "driver/ipmi". If done so, the configure does pick up checking sys/ipmi.h usability... yes checking sys/ipmi.h presence... yes checking for sys/ipmi.h? yes which is not the case without an installed "driver/ipmi" package: checking sys/ipmi.h usability... no checking sys/ipmi.h presence... no checking for sys/ipmi.h? no So I guess this is actually a bug in the omnios build script and should be fixed in core. Is everyone able to file bugs? If so, I'm happy to provide a bug report. My fixed version is available from scott.mathematik.uni-ulm.de and you'll find the sources on github (see https://github.com/stefri/omnios-build/tree/uulm.mawi/build/ipmitool). Cheers, Steffen Am 09.06.2013 um 21:58 schrieb Andy : > On Mon, 3 Jun 2013, Andy wrote: > > ; On Mon, 3 Jun 2013, takashi ary wrote: > ; > ; ; Hi Andy, > ; ; > ; ; Thanks for your comments. > ; ; > ; ; > This is an incompatibility between the version of IPMI tool included > ; ; > in OmniOS and the Dell BMC. I haven't looked into exactly what the > ; ; > problem is but 1.8.11 works fine so I just downloaded and built my > ; ; > own package around that. > ; ; > ; ; I built 1.8.12 (not 1.8.11) from modified "configure" file as follows. > ; > ; I just did the same and it works fine for me too. Sorry for the confusion, > ; I had assumed that it was the 1.8.12 version that caused the problem once > ; it was solved be me downloading and building my own .11. > > 1.8.12 will not connect to a remote BMC for SOL, 1.8.11 will. Apparently > that's the reason I built a 1.8.11 package for my servers. Now downgraded > again! Not an OmniOS problem unlike the strange ioctl() in the repository > version of ipmitool. > > v1.8.11 > > server1# (7) ipmitool -I lanplus -H server2.l -U root -f /tmp/f power status > Chassis Power is on > server1# (8) ipmitool -I lanplus -H server2.l -U root -f /tmp/f sol activate > Error activating SOL payload: Invalid data field in request > > v1.8.12 > > server1# (9) /opt/ipmitool/bin/ipmitool -I lanplus -H server2.l -U root -f /tmp/f power status > Chassis Power is on > server1# (10) /opt/ipmitool/bin/ipmitool -I lanplus -H server2.l -U root -f /tmp/f sol activate > [SOL Session operational. Use ~? for help] > > Private Data Network - Disconnect IMMEDIATELY if not authorised. > > server2 console login: ~. [terminated ipmitool] > > -- > Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From DvdKoppel at talpa.tv Mon Jul 8 12:33:22 2013 From: DvdKoppel at talpa.tv (Dennis van de Koppel) Date: Mon, 8 Jul 2013 12:33:22 +0000 Subject: [OmniOS-discuss] OmniOS domain related errors Message-ID: <1C2AC2E574FD5047B9BC9435056C4BC9129F05AE@TM-EXC01.talpamedia.local> Does anyone know what these errors mean and what i can do about them? They are showing up on both my OmniOS ZFS machines. Help is much appreciated! http://s22.postimg.org/6pfok05sh/Error_ZFS.jpg Regards, Dennis Dennis van de Koppel Systeembeheerder [cid:image0693f6.GIF at 68544f78.49978be1] Talpa Media B.V. Zevenend 45 - 1251 RL Laren P.O. Box 154 - 1250 AD Laren The Netherlands T +31 35 53 33 321 E DvdKoppel at talpa.tv W www.talpa.tv Chamber of commerce registration number 32083875 Talpa Media is part of the Talpa Group ________________________________ The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in relation to the contents of this information is strictly prohibited and may be unlawful. Neither the sender nor the represented institution are liable for the correct and complete transmission of the contents of an e-mail, or for its timely receipt. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image0693f6.GIF Type: image/gif Size: 1552 bytes Desc: image0693f6.GIF URL: From sk at kram.io Mon Jul 8 14:45:38 2013 From: sk at kram.io (Steffen Kram) Date: Mon, 8 Jul 2013 16:45:38 +0200 Subject: [OmniOS-discuss] OmniOS domain related errors In-Reply-To: <1C2AC2E574FD5047B9BC9435056C4BC9129F05AE@TM-EXC01.talpamedia.local> References: <1C2AC2E574FD5047B9BC9435056C4BC9129F05AE@TM-EXC01.talpamedia.local> Message-ID: <41F39E45-9D2D-4C74-AB87-6B0781AF8904@kram.io> The idmapd-Daemon belongs to the NFSv4 implementation. The problems with gssapi are pointing to problems with your kerberos configuration. Cheers, Steffen Am 08.07.2013 um 14:33 schrieb Dennis van de Koppel : > Does anyone know what these errors mean and what i can do about them? > They are showing up on both my OmniOS ZFS machines. > Help is much appreciated! > > http://s22.postimg.org/6pfok05sh/Error_ZFS.jpg > > Regards, > > Dennis > > > > > Dennis van de Koppel > Systeembeheerder > > > > Talpa Media B.V. > Zevenend 45 - 1251 RL Laren > P.O. Box 154 - 1250 AD Laren > The Netherlands > T +31 35 53 33 321 > E DvdKoppel at talpa.tv > W www.talpa.tv > > Chamber of commerce registration number 32083875 > > Talpa Media is part of the Talpa Group > > The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in relation to the contents of this information is strictly prohibited and may be unlawful. Neither the sender nor the represented institution are liable for the correct and complete transmission of the contents of an e-mail, or for its timely receipt. > > > > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From DvdKoppel at talpa.tv Mon Jul 8 15:02:43 2013 From: DvdKoppel at talpa.tv (Dennis van de Koppel) Date: Mon, 8 Jul 2013 15:02:43 +0000 Subject: [OmniOS-discuss] OmniOS domain related errors In-Reply-To: <07E113DB-5BD3-4072-A57E-AA780772D8BC@uni-ulm.de> References: <1C2AC2E574FD5047B9BC9435056C4BC9129F05AE@TM-EXC01.talpamedia.local> <07E113DB-5BD3-4072-A57E-AA780772D8BC@uni-ulm.de> Message-ID: <1C2AC2E574FD5047B9BC9435056C4BC9129F095B@TM-EXC01.talpamedia.local> This is our config... what can be wrong..? Looks very basic to me.. Or should i look @ the domain controller? # # CDDL HEADER START # # The contents of this file are subject to the terms of the # Common Development and Distribution License (the "License"). # You may not use this file except in compliance with the License. # # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE # or http://www.opensolaris.org/os/licensing. # See the License for the specific language governing permissions # and limitations under the License. # # When distributing Covered Code, include this CDDL HEADER in each # file and include the License file at usr/src/OPENSOLARIS.LICENSE. # If applicable, add the following below this CDDL HEADER, with the # fields enclosed by brackets "[]" replaced with your own identifying # information: Portions Copyright [yyyy] [name of copyright owner] # # CDDL HEADER END # # # Copyright 2007 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # ident ? "%Z%%M% ? %I% ? %E% SMI" # # krb5.conf template # In order to complete this configuration file # you will need to replace the ____ placeholders # with appropriate values for your network and uncomment the # appropriate entries. # [libdefaults] default_realm = TALPAMEDIA.LOCAL [realms] TALPAMEDIA.LOCAL = { kdc = 172.20.20.2 admin_server = 172.20.20.2 kpasswd_server = 172.20.20.2 kpasswd_protocol = SET_CHANGE } [domain_realm] .talpamedia.local = TALPAMEDIA.LOCAL [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log ? kdc_rotate = { # How often to rotate kdc.log. Logs will get rotated no more # often than the period, and less often if the KDC is not used # frequently. ? ? period = 1d # how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...) ? ? versions = 10 ? } [appdefaults] ? kinit = { ? ? renewable = true ? ? forwardable= true ? } -----Oorspronkelijk bericht----- Van: Steffen Kram [mailto:steffen.kram at uni-ulm.de] Verzonden: maandag 8 juli 2013 16:44 Aan: Dennis van de Koppel Onderwerp: Re: [OmniOS-discuss] OmniOS domain related errors The idmapd-Daemon belongs to the NFSv4 implementation. The problems with gssapi are pointing to problems with your kerberos configuration. Cheers, Steffen Am 08.07.2013 um 14:33 schrieb Dennis van de Koppel : > Does anyone know what these errors mean and what i can do about them? > They are showing up on both my OmniOS ZFS machines. > Help is much appreciated! > > http://s22.postimg.org/6pfok05sh/Error_ZFS.jpg > > Regards, > > Dennis > > > > > Dennis van de Koppel > Systeembeheerder > > > > Talpa Media B.V. > Zevenend 45 - 1251 RL Laren > P.O. Box 154 - 1250 AD Laren > The Netherlands > T +31 35 53 33 321 > E DvdKoppel at talpa.tv > W www.talpa.tv > > Chamber of commerce registration number 32083875 > > Talpa Media is part of the Talpa Group > > The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in relation to the contents of this information is strictly prohibited and may be unlawful. Neither the sender nor the represented institution are liable for the correct and complete transmission of the contents of an e-mail, or for its timely receipt. > > > > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From esproul at omniti.com Mon Jul 8 15:08:34 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 8 Jul 2013 11:08:34 -0400 Subject: [OmniOS-discuss] IPMI on Dell R720 In-Reply-To: <9DC398E6-DB7A-4BB3-9DBD-296BAB26CE79@kram.io> References: <9DC398E6-DB7A-4BB3-9DBD-296BAB26CE79@kram.io> Message-ID: On Mon, Jul 8, 2013 at 5:00 AM, Steffen Kram wrote: > Hi, > > I just ran into the same problem with the ipmi on a Supermicro X9SCM-F and had to rebuild the ipmitool package. I think the real problem is, that the omnios build.sh does not declare a dependency for "driver/ipmi". If done so, the configure does pick up > > checking sys/ipmi.h usability... yes > checking sys/ipmi.h presence... yes > checking for sys/ipmi.h? yes > > which is not the case without an installed "driver/ipmi" package: > > checking sys/ipmi.h usability... no > checking sys/ipmi.h presence... no > checking for sys/ipmi.h? no > > So I guess this is actually a bug in the omnios build script and should be fixed in core. Is everyone able to file bugs? If so, I'm happy to provide a bug report. Thanks for reporting this, Steffen. I've opened http://omnios.omniti.com/ticket.php/62. If you would like an account > > My fixed version is available from scott.mathematik.uni-ulm.de and you'll find the sources on github (see https://github.com/stefri/omnios-build/tree/uulm.mawi/build/ipmitool). I believe the driver package should be a build dependency of ipmitool and is not necessary for runtime, so I would change DEPENDS_IPS to BUILD_DEPENDS_IPS so that the build script will require it to be installed before building. Feel free to send us a PR for that. Eric From esproul at omniti.com Mon Jul 8 15:11:44 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 8 Jul 2013 11:11:44 -0400 Subject: [OmniOS-discuss] IPMI on Dell R720 In-Reply-To: References: <9DC398E6-DB7A-4BB3-9DBD-296BAB26CE79@kram.io> Message-ID: On Mon, Jul 8, 2013 at 11:08 AM, Eric Sproul wrote: > Thanks for reporting this, Steffen. I've opened > http://omnios.omniti.com/ticket.php/62. If you would like an account Oops, this was incomplete when I hit "send". If you'd like an account that lets you handle tickets and edit the wiki, let us know. We'll use your email address as the username and need an Apache-style password hash, which you can generate with htpasswd or at sites like http://aspirine.org/htpasswd_en.html Eric From daleg at omniti.com Mon Jul 8 15:26:10 2013 From: daleg at omniti.com (Dale Ghent) Date: Mon, 8 Jul 2013 11:26:10 -0400 Subject: [OmniOS-discuss] IPMI on Dell R720 In-Reply-To: <9DC398E6-DB7A-4BB3-9DBD-296BAB26CE79@kram.io> References: <9DC398E6-DB7A-4BB3-9DBD-296BAB26CE79@kram.io> Message-ID: <7FFCEFD3-7427-40EE-BE98-1086E3CBD837@omniti.com> Thanks for reporting this, Steffen. I've committed a fix (using BUILD_DEPENDS_IPS rather than DEPENDS_IPS) and ticket 62 that Eric opened is now closed. It's in the master and 006 branches. /dale On Jul 8, 2013, at 5:00 AM, Steffen Kram wrote: > Hi, > > I just ran into the same problem with the ipmi on a Supermicro X9SCM-F and had to rebuild the ipmitool package. I think the real problem is, that the omnios build.sh does not declare a dependency for "driver/ipmi". If done so, the configure does pick up > > checking sys/ipmi.h usability... yes > checking sys/ipmi.h presence... yes > checking for sys/ipmi.h? yes > > which is not the case without an installed "driver/ipmi" package: > > checking sys/ipmi.h usability... no > checking sys/ipmi.h presence... no > checking for sys/ipmi.h? no > > So I guess this is actually a bug in the omnios build script and should be fixed in core. Is everyone able to file bugs? If so, I'm happy to provide a bug report. > > My fixed version is available from scott.mathematik.uni-ulm.de and you'll find the sources on github (see https://github.com/stefri/omnios-build/tree/uulm.mawi/build/ipmitool). > > Cheers, > Steffen > > > > > Am 09.06.2013 um 21:58 schrieb Andy : > >> On Mon, 3 Jun 2013, Andy wrote: >> >> ; On Mon, 3 Jun 2013, takashi ary wrote: >> ; >> ; ; Hi Andy, >> ; ; >> ; ; Thanks for your comments. >> ; ; >> ; ; > This is an incompatibility between the version of IPMI tool included >> ; ; > in OmniOS and the Dell BMC. I haven't looked into exactly what the >> ; ; > problem is but 1.8.11 works fine so I just downloaded and built my >> ; ; > own package around that. >> ; ; >> ; ; I built 1.8.12 (not 1.8.11) from modified "configure" file as follows. >> ; >> ; I just did the same and it works fine for me too. Sorry for the confusion, >> ; I had assumed that it was the 1.8.12 version that caused the problem once >> ; it was solved be me downloading and building my own .11. >> >> 1.8.12 will not connect to a remote BMC for SOL, 1.8.11 will. Apparently >> that's the reason I built a 1.8.11 package for my servers. Now downgraded >> again! Not an OmniOS problem unlike the strange ioctl() in the repository >> version of ipmitool. >> >> v1.8.11 >> >> server1# (7) ipmitool -I lanplus -H server2.l -U root -f /tmp/f power status >> Chassis Power is on >> server1# (8) ipmitool -I lanplus -H server2.l -U root -f /tmp/f sol activate >> Error activating SOL payload: Invalid data field in request >> >> v1.8.12 >> >> server1# (9) /opt/ipmitool/bin/ipmitool -I lanplus -H server2.l -U root -f /tmp/f power status >> Chassis Power is on >> server1# (10) /opt/ipmitool/bin/ipmitool -I lanplus -H server2.l -U root -f /tmp/f sol activate >> [SOL Session operational. Use ~? for help] >> >> Private Data Network - Disconnect IMMEDIATELY if not authorised. >> >> server2 console login: ~. [terminated ipmitool] >> >> -- >> Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk >> Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ >> Registered in England and Wales | Company number 4899123 >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From henson at acm.org Tue Jul 9 02:01:13 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 08 Jul 2013 19:01:13 -0700 Subject: [OmniOS-discuss] expected memory bandwidth of Supermicro X9DRi-F and X9SRI-F Message-ID: <51DB6EE9.6020808@acm.org> I have two servers I'm putting together, one using the X9SRI-F and the other the X9DRi-F motherboard. Both have Intel Xeon E5-2620 processors (one for the X9SRI-F and two for the X9DRi-F). Both have Crucial CT2KIT102472BB160B (2 x 8G 1Gx72 DDR3 PC3-12800 Reg/ECC) DIMMs installed (6 on X9SRI-F for 48G, 8 on X9DRi-F for 64G). Testing the memory, the X9SRI-F shows bandwidth of about 12GB/s, whereas the X9DRi-F shows only about 8GB/s. This seems considerably lower than the 42GB/s bandwidth the E5-2620 is supposed to support, even considering this isn't the most expensive/fasted RAM on the market. I'll also suprised at the 4GB/s difference between the single-proc and dual-proc board. I was wondering if anybody else was using these boards and if so what memory bandwidth memtest86+ reports, as I've been unable to find a good source of expected bandwidth (versus theoretical maximum bandwidth). I asked supermicro if it was expected to have such a difference in performance between the single processor versus dual processor board, and all they would tell me is "we don't support that memory" . Thanks? From henson at acm.org Tue Jul 9 02:21:59 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 08 Jul 2013 19:21:59 -0700 Subject: [OmniOS-discuss] Supermicro BIOS updates Message-ID: <51DB73C7.70105@acm.org> Sorry for two potentially OT supermicro posts in a row :), I just know they are really popular for illumos servers and there's such a wealth of knowledge on these mailing lists. I usually update firmware/BIOS on a fairly regular basis on my servers, but supermicro has a fairly scary warning on their download page: ------ WARNING! Please do not download / upgrade the BIOS/Firmware UNLESS your system has a BIOS/firmware-related issue. Flashing the wrong BIOS/firmware can cause irreparable damage to the system. In no event shall Supermicro be liable for direct, indirect, special, incidental, or consequential damages arising from a BIOS/firmware update. ------ Where it seems they pretty much do not want you to ever update unless you know of a specific issue the update will solve. Of course, they also don't post changelogs with their bios updates, so it's kind of hard to know 8-/. I can't remember the last time I had a box die due to a corrupted bios update (most of the ones I've worked with won't even let you try to flash the wrong firmware), I was wondering if that's a problem with supermicro boards to the point where they actively discourage updates? Their technical support sent me a changelog for the motherboard I'm working with upon request (seems like it would be a timesaver for them to just post it in the first place), and I think I do want to go ahead and update the bios. I haven't had to boot DOS for a bios update in a *long* time, my workstations for years have supported just sticking in a USB flash drive with the image on it and updating from the bios itself, and the servers I've been using supported bios updates via the IPMI web interface or CLI. What's the preferred way to generate a bootable DOS image with the bios update utility and image on it nowadays? I was thinking of just downloading a freeDOS floppy image, loopback mounting it to copy on the additional files, and then booting it via the IPMI remote media option. Is there an easier way? Thanks much? From skiselkov.ml at gmail.com Tue Jul 9 08:25:10 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Tue, 09 Jul 2013 09:25:10 +0100 Subject: [OmniOS-discuss] Supermicro BIOS updates In-Reply-To: <51DB73C7.70105@acm.org> References: <51DB73C7.70105@acm.org> Message-ID: <51DBC8E6.3020000@gmail.com> On 09/07/2013 03:21, Paul B. Henson wrote: > Sorry for two potentially OT supermicro posts in a row :), I just know > they are really popular for illumos servers and there's such a wealth of > knowledge on these mailing lists. > > I usually update firmware/BIOS on a fairly regular basis on my servers, > but supermicro has a fairly scary warning on their download page: > > ------ > WARNING! > Please do not download / upgrade the BIOS/Firmware UNLESS your system > has a BIOS/firmware-related issue. Flashing the wrong BIOS/firmware can > cause irreparable damage to the system. > > In no event shall Supermicro be liable for direct, indirect, special, > incidental, or consequential damages arising from a BIOS/firmware update. > ------ > > Where it seems they pretty much do not want you to ever update unless > you know of a specific issue the update will solve. Of course, they also > don't post changelogs with their bios updates, so it's kind of hard to > know 8-/. I can't remember the last time I had a box die due to a > corrupted bios update (most of the ones I've worked with won't even let > you try to flash the wrong firmware), I was wondering if that's a > problem with supermicro boards to the point where they actively > discourage updates? > > Their technical support sent me a changelog for the motherboard I'm > working with upon request (seems like it would be a timesaver for them > to just post it in the first place), and I think I do want to go ahead > and update the bios. I haven't had to boot DOS for a bios update in a > *long* time, my workstations for years have supported just sticking in a > USB flash drive with the image on it and updating from the bios itself, > and the servers I've been using supported bios updates via the IPMI web > interface or CLI. What's the preferred way to generate a bootable DOS > image with the bios update utility and image on it nowadays? I was > thinking of just downloading a freeDOS floppy image, loopback mounting > it to copy on the additional files, and then booting it via the IPMI > remote media option. Is there an easier way? > > Thanks much? Get something like Boot Flash DOS (BFD.exe) and create a bootable USB stick in Windows. Then load on it the additional files you need, boot and execute whatever monkey business you need to. I personally prefer a simple DOS flashing tool over some super-smart EFI clusterf**k any day of the week. Cheers, -- Saso From jon.dison at gmail.com Tue Jul 9 03:51:04 2013 From: jon.dison at gmail.com (Jon Dison) Date: Mon, 8 Jul 2013 23:51:04 -0400 Subject: [OmniOS-discuss] [smartos-discuss] Supermicro BIOS updates In-Reply-To: <51DB73C7.70105@acm.org> References: <51DB73C7.70105@acm.org> Message-ID: That is a very common school-of-thought... If you're not experiencing trouble with your system, why go out and update the BIOS? SuperMicro is just trying to protect their technically-challenged customers from damaging their systems by applying BIOS updates for no good reason. That being said, I own and have deployed systems with SuperMicro boards (mostly X9SCM-F) and always update the BIOS to the latest available on the site at the time.... I have yet to encounter any issues. The only complaint I have about SuperMicro BIOSes is probably true of many motherboard manufacturers.... Certain processors will only run in certain boards with certain BIOS revisions. Sometimes you get an older board from a vendor and have to find an older chip to run the BIOS update so that you can install the newer chip. Not a huge deal I know, but just kind of a pain. On Mon, Jul 8, 2013 at 10:21 PM, Paul B. Henson wrote: > Sorry for two potentially OT supermicro posts in a row :), I just know > they are really popular for illumos servers and there's such a wealth of > knowledge on these mailing lists. > > I usually update firmware/BIOS on a fairly regular basis on my servers, > but supermicro has a fairly scary warning on their download page: > > ------ > WARNING! > Please do not download / upgrade the BIOS/Firmware UNLESS your system has > a BIOS/firmware-related issue. Flashing the wrong BIOS/firmware can cause > irreparable damage to the system. > > In no event shall Supermicro be liable for direct, indirect, special, > incidental, or consequential damages arising from a BIOS/firmware update. > ------ > > Where it seems they pretty much do not want you to ever update unless you > know of a specific issue the update will solve. Of course, they also don't > post changelogs with their bios updates, so it's kind of hard to know 8-/. > I can't remember the last time I had a box die due to a corrupted bios > update (most of the ones I've worked with won't even let you try to flash > the wrong firmware), I was wondering if that's a problem with supermicro > boards to the point where they actively discourage updates? > > Their technical support sent me a changelog for the motherboard I'm > working with upon request (seems like it would be a timesaver for them to > just post it in the first place), and I think I do want to go ahead and > update the bios. I haven't had to boot DOS for a bios update in a *long* > time, my workstations for years have supported just sticking in a USB flash > drive with the image on it and updating from the bios itself, and the > servers I've been using supported bios updates via the IPMI web interface > or CLI. What's the preferred way to generate a bootable DOS image with the > bios update utility and image on it nowadays? I was thinking of just > downloading a freeDOS floppy image, loopback mounting it to copy on the > additional files, and then booting it via the IPMI remote media option. Is > there an easier way? > > Thanks much? > > > ------------------------------**------------- > smartos-discuss > Archives: https://www.listbox.com/**member/archive/184463/=now > RSS Feed: https://www.listbox.com/**member/archive/rss/184463/** > 24572942-77406857 > Modify Your Subscription: https://www.listbox.com/** > member/?member_id=24572942&id_**secret=24572942-8aaf8efc > Powered by Listbox: http://www.listbox.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Tue Jul 9 14:09:57 2013 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 9 Jul 2013 09:09:57 -0500 (CDT) Subject: [OmniOS-discuss] expected memory bandwidth of Supermicro X9DRi-F and X9SRI-F In-Reply-To: <51DB6EE9.6020808@acm.org> References: <51DB6EE9.6020808@acm.org> Message-ID: On Mon, 8 Jul 2013, Paul B. Henson wrote: > I have two servers I'm putting together, one using the X9SRI-F and the other > the X9DRi-F motherboard. Both have Intel Xeon E5-2620 processors (one for the > X9SRI-F and two for the X9DRi-F). Both have Crucial CT2KIT102472BB160B (2 x > 8G 1Gx72 DDR3 PC3-12800 Reg/ECC) DIMMs installed > (6 on X9SRI-F for 48G, 8 on X9DRi-F for 64G). Testing the memory, the X9SRI-F > shows bandwidth of about 12GB/s, whereas the X9DRi-F shows only about 8GB/s. > This seems considerably lower than the 42GB/s bandwidth the > E5-2620 is supposed to support, even considering this isn't the most > expensive/fasted RAM on the market. I'll also suprised at the 4GB/s > difference between the single-proc and dual-proc board. > > I was wondering if anybody else was using these boards and if so what memory > bandwidth memtest86+ reports, as I've been unable to find a good source of > expected bandwidth (versus theoretical maximum bandwidth). I asked supermicro > if it was expected to have such a difference in performance between the > single processor versus dual processor board, and all they would tell me is > "we don't support that memory" . There would be a big difference between peak (carefully multi-threaded with non-overlapping access across memory channels and DIMMs) and single-threaded memory bandwidth. More CPUs means more parallel channels to the memory. Each motherboard has an ideal DIMM layout for maximum bandwidth for installed memory. If too few large DIMMs are installed then not enough memory I/Os can occur at once. If too many smaller DIMMs are installed, then the memory needs to be clocked slower so that errors don't occur. With many DIMMs, using buffered memory can keep the clock speeds up. Regardless, actual performance depends on how your applications use the memory. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From jim.oltman at gmail.com Tue Jul 9 14:25:29 2013 From: jim.oltman at gmail.com (Jim Oltman) Date: Tue, 9 Jul 2013 09:25:29 -0500 Subject: [OmniOS-discuss] [smartos-discuss] Supermicro BIOS updates In-Reply-To: References: <51DB73C7.70105@acm.org> Message-ID: Use YUMI . You can have multiple OSes or utilities loaded on your USB disk and can boot to any of them. very handy for BIOS updates, or GParted, or any number of distros. On Mon, Jul 8, 2013 at 10:51 PM, Jon Dison wrote: > That is a very common school-of-thought... If you're not experiencing > trouble with your system, why go out and update the BIOS? SuperMicro is > just trying to protect their technically-challenged customers from damaging > their systems by applying BIOS updates for no good reason. > > That being said, I own and have deployed systems with SuperMicro boards > (mostly X9SCM-F) and always update the BIOS to the latest available on the > site at the time.... I have yet to encounter any issues. > > The only complaint I have about SuperMicro BIOSes is probably true of many > motherboard manufacturers.... Certain processors will only run in certain > boards with certain BIOS revisions. Sometimes you get an older board from > a vendor and have to find an older chip to run the BIOS update so that you > can install the newer chip. Not a huge deal I know, but just kind of a > pain. > > > On Mon, Jul 8, 2013 at 10:21 PM, Paul B. Henson wrote: > >> Sorry for two potentially OT supermicro posts in a row :), I just know >> they are really popular for illumos servers and there's such a wealth of >> knowledge on these mailing lists. >> >> I usually update firmware/BIOS on a fairly regular basis on my servers, >> but supermicro has a fairly scary warning on their download page: >> >> ------ >> WARNING! >> Please do not download / upgrade the BIOS/Firmware UNLESS your system has >> a BIOS/firmware-related issue. Flashing the wrong BIOS/firmware can cause >> irreparable damage to the system. >> >> In no event shall Supermicro be liable for direct, indirect, special, >> incidental, or consequential damages arising from a BIOS/firmware update. >> ------ >> >> Where it seems they pretty much do not want you to ever update unless you >> know of a specific issue the update will solve. Of course, they also don't >> post changelogs with their bios updates, so it's kind of hard to know 8-/. >> I can't remember the last time I had a box die due to a corrupted bios >> update (most of the ones I've worked with won't even let you try to flash >> the wrong firmware), I was wondering if that's a problem with supermicro >> boards to the point where they actively discourage updates? >> >> Their technical support sent me a changelog for the motherboard I'm >> working with upon request (seems like it would be a timesaver for them to >> just post it in the first place), and I think I do want to go ahead and >> update the bios. I haven't had to boot DOS for a bios update in a *long* >> time, my workstations for years have supported just sticking in a USB flash >> drive with the image on it and updating from the bios itself, and the >> servers I've been using supported bios updates via the IPMI web interface >> or CLI. What's the preferred way to generate a bootable DOS image with the >> bios update utility and image on it nowadays? I was thinking of just >> downloading a freeDOS floppy image, loopback mounting it to copy on the >> additional files, and then booting it via the IPMI remote media option. Is >> there an easier way? >> >> Thanks much? >> >> >> ------------------------------**------------- >> smartos-discuss >> Archives: https://www.listbox.com/**member/archive/184463/=now >> RSS Feed: https://www.listbox.com/**member/archive/rss/184463/** >> 24572942-77406857 >> Modify Your Subscription: https://www.listbox.com/** >> member/?member_id=24572942&id_**secret=24572942-8aaf8efc >> Powered by Listbox: http://www.listbox.com >> > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith.wesolowski at joyent.com Tue Jul 9 15:46:06 2013 From: keith.wesolowski at joyent.com (Keith Wesolowski) Date: Tue, 9 Jul 2013 15:46:06 +0000 Subject: [OmniOS-discuss] [smartos-discuss] Supermicro BIOS updates In-Reply-To: <51DB73C7.70105@acm.org> References: <51DB73C7.70105@acm.org> Message-ID: <20130709154606.GA516@joyent.com> On Mon, Jul 08, 2013 at 07:21:59PM -0700, Paul B. Henson wrote: > I usually update firmware/BIOS on a fairly regular basis on my servers, > but supermicro has a fairly scary warning on their download page: > > ------ > WARNING! > Please do not download / upgrade the BIOS/Firmware UNLESS your system > has a BIOS/firmware-related issue. Flashing the wrong BIOS/firmware can > cause irreparable damage to the system. > > In no event shall Supermicro be liable for direct, indirect, special, > incidental, or consequential damages arising from a BIOS/firmware update. > ------ > > Where it seems they pretty much do not want you to ever update unless > you know of a specific issue the update will solve. Of course, they also > don't post changelogs with their bios updates, so it's kind of hard to > know 8-/. I can't remember the last time I had a box die due to a The solution here is to press -- hard -- on your sales rep to provide those changelogs. We push on them, and if more people are pushing they will have more incentive to clean this up. This is fundamentally a risk-management exercise; SMCI is not at all wrong to recommend against "random walk" changes to working systems. In general, my approach is to invest effort up front in qualifying systems with specific hardware, firmware, and software and then never change them unless a problem arises. This is borne of a very, very, very long and painful career full of firmware bugs and subtle changes that "seemed to work fine on the developer's Windows 98 desktop!" but in fact break other software or simply don't work properly at all. You are certainly free to choose a different approach, but in order to do so you need the right information. You'll need this anyway, because if and when you do hit a problem, you'll have to decide how to upgrade, what to upgrade to, and which existing systems (if any) you want to take a painful outage to upgrade. You'll also need to re-qualify from scratch with whatever you decide to upgrade to, which means you need a test plan. Knowing what has changed and why is crucial to all of this. So push. Hard. > corrupted bios update (most of the ones I've worked with won't even let > you try to flash the wrong firmware), I was wondering if that's a > problem with supermicro boards to the point where they actively > discourage updates? No. They know better than you just how shoddy their firmware is, though. It's an industry-wide problem; engineering practices in firmware development are horrific, code quality is abysmal, and the mind-boggling secrecy of all the participants from Intel to the BIOS duopolists to the OEMs precludes collaboration, self-reliance, and effective end-user testing. Everyone knows this and it is not specific to SMCI. Basically all firmware on all devices is like this; the BIOS is middle of the pack all things considered (if you ever want to shatter some illusions, grab SMCI's "GPL firmware bundle" and take a look at the bits of source for the BMC that are in it). With all that in mind, if you find something that works for your application, you stick with it and by God don't even think about changing anything without a damn good reason. It's often a challenge to get your vendors and staff to appreciate the importance of this and get consistently correct systems into production; the last thing you need or want is to layer deliberate random change on top of it. > Their technical support sent me a changelog for the motherboard I'm > working with upon request (seems like it would be a timesaver for them > to just post it in the first place), and I think I do want to go ahead Yep. And what is available is often maddeningly short on details, assuming you can even read it. It helps if you understand Mandarin, to overlay that language's grammar onto the English words in the documents. But still, push hard. Make them clean this up -- better documents, posted automatically. They'll do it if they have the right incentive. > and update the bios. I haven't had to boot DOS for a bios update in a > *long* time, my workstations for years have supported just sticking in a > USB flash drive with the image on it and updating from the bios itself, > and the servers I've been using supported bios updates via the IPMI web > interface or CLI. What's the preferred way to generate a bootable DOS > image with the bios update utility and image on it nowadays? I was You might consider having a look at https://github.com/joyent/sdcboot. It's not complete (unfortunately there are a few other bits that are SDC-only and thus not available) but you can easily add stuff for your board. > thinking of just downloading a freeDOS floppy image, loopback mounting > it to copy on the additional files, and then booting it via the IPMI > remote media option. Is there an easier way? That's basically what our build system does, except for the last part. The BMC remote media (it's not really part of IPMI) is horrible and usually doesn't work; it also requires a lot of manual intervention to use. We just put this, along with tools for Joyent boards and other devices, directly into the USB key and boot it that way via a separate GRUB option. You could also, if you were feeling clever, set things up to PXE boot this. From keith.wesolowski at joyent.com Tue Jul 9 15:53:24 2013 From: keith.wesolowski at joyent.com (Keith Wesolowski) Date: Tue, 9 Jul 2013 15:53:24 +0000 Subject: [OmniOS-discuss] [smartos-discuss] expected memory bandwidth of Supermicro X9DRi-F and X9SRI-F In-Reply-To: <51DB6EE9.6020808@acm.org> References: <51DB6EE9.6020808@acm.org> Message-ID: <20130709155324.GB516@joyent.com> On Mon, Jul 08, 2013 at 07:01:13PM -0700, Paul B. Henson wrote: > I have two servers I'm putting together, one using the X9SRI-F and the > other the X9DRi-F motherboard. Both have Intel Xeon E5-2620 processors > (one for the X9SRI-F and two for the X9DRi-F). Both have Crucial > CT2KIT102472BB160B (2 x 8G 1Gx72 DDR3 PC3-12800 Reg/ECC) DIMMs installed > (6 on X9SRI-F for 48G, 8 on X9DRi-F for 64G). Testing the memory, the > X9SRI-F shows bandwidth of about 12GB/s, whereas the X9DRi-F shows only > about 8GB/s. This seems considerably lower than the 42GB/s bandwidth the > E5-2620 is supposed to support, even considering this isn't the most > expensive/fasted RAM on the market. I'll also suprised at the 4GB/s > difference between the single-proc and dual-proc board. > > I was wondering if anybody else was using these boards and if so what > memory bandwidth memtest86+ reports, as I've been unable to find a good > source of expected bandwidth (versus theoretical maximum bandwidth). I > asked supermicro if it was expected to have such a difference in > performance between the single processor versus dual processor board, > and all they would tell me is "we don't support that memory" . Get the documents from Intel describing expected memory bandwidth and optimal configurations. There are significant -- nay, dramatic -- differences depending on how you populate your controllers and channels. It's not surprising that having only one CPU would significantly degrade performance, since the MCs are part of the CPUs. There are also population rules based on DIMM speed, rank count, power levels, and so on, and if you do not follow them you will have reduced performance. From omnios at citrus-it.net Tue Jul 9 22:04:46 2013 From: omnios at citrus-it.net (Andy) Date: Tue, 9 Jul 2013 22:04:46 +0000 (GMT) Subject: [OmniOS-discuss] Zones failing to start after upgrade Message-ID: I just did my first kernel update on an OmniOS system with some non-global zones and they failed to start following the reboot. Fixed it by patching the org.opensolaris.libbe:parentbe property on each zbe dataset but can anyone tell me if this is the recommended process? Did I miss something? Thanks! # pkg update --be-name omnios-r151006j after reboot: # zoneadm -z ns1 boot zone 'ns1': ERROR: no active dataset. zone 'ns1': zoneadm: zone 'ns1': call to zoneadmd failed zsh: exit 1 zoneadm -z ns1 boot # zfs get all data/zone/ns1/ROOT/zbe NAME PROPERTY VALUE data/zone/ns1/ROOT/zbe canmount noauto data/zone/ns1/ROOT/zbe org.opensolaris.libbe:parentbe (null) data/zone/ns1/ROOT/zbe org.opensolaris.libbe:active on and fixed with: zfs set org.opensolaris.libbe:parentbe=xxxx data/zone/ns1/ROOT/zbe -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From ben at fluffy.co.uk Wed Jul 10 08:00:47 2013 From: ben at fluffy.co.uk (Ben Summers) Date: Wed, 10 Jul 2013 09:00:47 +0100 Subject: [OmniOS-discuss] Zones failing to start after upgrade In-Reply-To: References: Message-ID: On 9 Jul 2013, at 23:04, Andy wrote: > > I just did my first kernel update on an OmniOS system with some non-global > zones and they failed to start following the reboot. Fixed it by patching > the org.opensolaris.libbe:parentbe property on each zbe dataset but can > anyone tell me if this is the recommended process? Did I miss something? Did you pkg update the zones too? After a conversation on IRC about the OmniOS upgrade process, I wrote up the notes below. I'm hoping they'll pop them on the OmniOS wiki, as it currently doesn't mention zones and updates. Ben Upgrading a system with zones Zones are completely independent system images, and running pkg update to upgrade the global zone does not update the zone images. You must upgrade each of the zones to get the latest packages, which is especially important when the kernel is updated to keep the system libraries matching the kernel. The following instructions will always apply an update successfully and safely: * Shut down each zone: zlogin shutdown -i5 -g0 -y * Detach each zone: zoneadm -z detach * Upgrade the global zone: pkg update * Reboot the server * Update the image for each zone: pkg -R /root update * Attach each zone: zoneadm -z attach * Boot each zone: zoneadm -z boot These instructions can result in more downtime than is ideal, and update all the packages in every zone. The release notes will list any shortcuts for updating the OS with less downtime, but if you are in any doubt, you should follow the instructions above. If you do not wish to update the packages in the zones any more than is absolutely necessary, omit the "pkg -R" step. When the zone is attached, the minimal updates for successful execution of software within the zone will be applied. > > Thanks! > > # pkg update --be-name omnios-r151006j > > after reboot: > > # zoneadm -z ns1 boot > zone 'ns1': ERROR: no active dataset. > zone 'ns1': > zoneadm: zone 'ns1': call to zoneadmd failed > zsh: exit 1 zoneadm -z ns1 boot > > # zfs get all data/zone/ns1/ROOT/zbe > NAME PROPERTY VALUE > data/zone/ns1/ROOT/zbe canmount noauto > data/zone/ns1/ROOT/zbe org.opensolaris.libbe:parentbe (null) > data/zone/ns1/ROOT/zbe org.opensolaris.libbe:active on > > and fixed with: > > zfs set org.opensolaris.libbe:parentbe=xxxx data/zone/ns1/ROOT/zbe > > -- > Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- http://bens.me.uk From omnios at citrus-it.net Wed Jul 10 09:32:33 2013 From: omnios at citrus-it.net (Andy) Date: Wed, 10 Jul 2013 09:32:33 +0000 (GMT) Subject: [OmniOS-discuss] Zones failing to start after upgrade In-Reply-To: References: Message-ID: On Wed, 10 Jul 2013, Ben Summers wrote: ; ; On 9 Jul 2013, at 23:04, Andy wrote: ; ; > ; > I just did my first kernel update on an OmniOS system with some non-global ; > zones and they failed to start following the reboot. Fixed it by patching ; > the org.opensolaris.libbe:parentbe property on each zbe dataset but can ; > anyone tell me if this is the recommended process? Did I miss something? ; ; Did you pkg update the zones too? Yes, but after getting them back online. The instructions on the Wiki for the last kernel update release say to do that as a last step. " Updates may be applied without detaching non-global zones, though we recommend that zones still be shut down during the update process. Zones attached to the system during this update will get a new ZFS dataset that matches the global zone's new BE. After booting into the new BE, shut down the non-global zone again and run pkg -R /root update " It seems that something went wrong with my update as the non-global zones didn't get a ZFS dataset matching the new BE, or that the instructions are wrong in some way. Detaching the zones seems safest for the future, thanks. Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From esproul at omniti.com Wed Jul 10 14:12:33 2013 From: esproul at omniti.com (Eric Sproul) Date: Wed, 10 Jul 2013 10:12:33 -0400 Subject: [OmniOS-discuss] Zones failing to start after upgrade In-Reply-To: References: Message-ID: On Wed, Jul 10, 2013 at 4:00 AM, Ben Summers wrote: > After a conversation on IRC about the OmniOS upgrade process, I wrote up the notes below. I'm hoping they'll pop them on the OmniOS wiki, as it currently doesn't mention zones and updates. Ben, I've added your notes: http://omnios.omniti.com/wiki.php/GeneralAdministration#UpgradingWithNon-GlobalZones I made a few modifications to make it clearer that the full pkg update within the zone is optional. I also want to ensure that folks read the release notes as well, especially when upgrading to a new stable release, as there may be additional steps required. Thanks for writing that up. Eric From henson at acm.org Thu Jul 11 00:08:35 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jul 2013 17:08:35 -0700 Subject: [OmniOS-discuss] [smartos-discuss] expected memory bandwidth of Supermicro X9DRi-F and X9SRI-F In-Reply-To: <20130709155324.GB516@joyent.com> References: <51DB6EE9.6020808@acm.org> <20130709155324.GB516@joyent.com> Message-ID: <51DDF783.4020804@acm.org> On 7/9/2013 8:53 AM, Keith Wesolowski wrote: > Get the documents from Intel describing expected memory bandwidth and > optimal configurations. There are significant -- nay, dramatic -- > differences depending on how you populate your controllers and channels. > It's not surprising that having only one CPU would significantly degrade > performance, since the MCs are part of the CPUs. There are also > population rules based on DIMM speed, rank count, power levels, and so > on, and if you do not follow them you will have reduced performance. Under memtest86+, the *dual* processor board was actually reporting less bandwidth than the single processor board. I asked supermicro support what the expected bandwidth would be using their supported memory, and they were kind enough to run some benchmarks and send me the results. They recommended using http://www.cs.virginia.edu/stream/ for benchmarking. On the X9SRI with 32G (4x8G) they were getting roughly 30GB/s. On the same board with 48G (6x8G) they were only getting 18GB/s. They said 6 DIMMs isn't balanced, resulting in the lower performance. On the X9DRi with 64G (8x8G), they were getting roughly 40GB/s, pretty close to the theoretical maximum. I'm going to try the same benchmark on my equipment. I originally had 32G in the X9SRi board, I recently picked up an additional 16G as to increase the ARC, I didn't realize that would result in decreased memory performance. The motherboard manual doesn't mention balancing the DIMMs, only which order to install them in depending on how many you have. I don't really want to add more memory to that box, so I guess I'll have to decide between the trade-off of increased ARC vs decreased memory bandwidth. I'm going to have 64G in the X9DRi before before I deploy it, unfortunately one of the kits was defective and right now it only has 48G pending RMA. From henson at acm.org Thu Jul 11 00:13:43 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jul 2013 17:13:43 -0700 Subject: [OmniOS-discuss] [smartos-discuss] Supermicro BIOS updates In-Reply-To: References: <51DB73C7.70105@acm.org> Message-ID: <51DDF8B7.2040905@acm.org> On 7/8/2013 8:51 PM, Jon Dison wrote: > That is a very common school-of-thought... If you're not experiencing > trouble with your system, why go out and update the BIOS? SuperMicro is > just trying to protect their technically-challenged customers from > damaging their systems by applying BIOS updates for no good reason. Understood, it's just such a diametrically opposed school of thought compared to some of the server vendors whose technical support asks you if you have the latest version of bio/firmware/everything for any ticket you open, and then don't want to help you until you update, even if the updates likely have nothing to do with your problem . And then intentionally or not, the way supermicro expresses that school of thought on their site induces fear of failure and broken equipment 8-/. Thanks for the feedback... > certain boards with certain BIOS revisions. Sometimes you get an older > board from a vendor and have to find an older chip to run the BIOS > update so that you can install the newer chip. Not a huge deal I know, > but just kind of a pain. Yeah; more of a pain if you're building a box at home and don't exactly have a pile of spare processors sitting around :). From henson at acm.org Thu Jul 11 00:21:12 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jul 2013 17:21:12 -0700 Subject: [OmniOS-discuss] Supermicro BIOS updates In-Reply-To: <51DBC8E6.3020000@gmail.com> References: <51DB73C7.70105@acm.org> <51DBC8E6.3020000@gmail.com> Message-ID: <51DDFA78.4090506@acm.org> On 7/9/2013 1:25 AM, Saso Kiselkov wrote: > Get something like Boot Flash DOS (BFD.exe) and create a bootable USB > stick in Windows. Meh, involving Windows in the process ;)? > and execute whatever monkey business you need to. I personally prefer a > simple DOS flashing tool over some super-smart EFI clusterf**k any day > of the week. Although they have other faults, I've been pretty happy with firmware/bios updates on my Sun servers, you can just use the bmc cli to suck the update over via tftp, and it installs both the bmc/ipmi firmware and the bios from one package. I think I'm going to try using unetbootin to build a FreeDOS USB image and see how that works out. I was originally going to use the virtual media, but found a few horror stories about that flaking out in the middle of flashing, which doesn't seem like a good thing to have happen :(. It's not too much trouble to physically visit the machine and shove in a USB stick. Thanks? From henson at acm.org Thu Jul 11 00:28:12 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jul 2013 17:28:12 -0700 Subject: [OmniOS-discuss] [smartos-discuss] Supermicro BIOS updates In-Reply-To: References: <51DB73C7.70105@acm.org> Message-ID: <51DDFC1C.50304@acm.org> On 7/9/2013 7:25 AM, Jim Oltman wrote: > Use YUMI . That looks interesting; I was going to try unetbootin, which seems similar although I'm not sure if it supports a menu allowing multiple different things to be booted, or just one thing at a time. But it does have a Linux version? Thanks? From henson at acm.org Thu Jul 11 00:42:08 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jul 2013 17:42:08 -0700 Subject: [OmniOS-discuss] [smartos-discuss] Supermicro BIOS updates In-Reply-To: <20130709154606.GA516@joyent.com> References: <51DB73C7.70105@acm.org> <20130709154606.GA516@joyent.com> Message-ID: <51DDFF60.8000603@acm.org> On 7/9/2013 8:46 AM, Keith Wesolowski wrote: > The solution here is to press -- hard -- on your sales rep to > provide those changelogs. Yeah, I don't exactly have a sales rep ;), my day job doesn't use Supermicro, and the bits and pieces I buy for myself or other projects don't exactly make me a major customer :). > We push on them, and if more people are pushing they will have more > incentive to clean this up. On the bright side, I got a fairly quick response from technical support when I requested them. > Yep. And what is available is often maddeningly short on details, > assuming you can even read it. It helps if you understand Mandarin, > to overlay that language's grammar onto the English words in the > documents. Yes, there were definitely some of those ;) : 12.Improved OOB BIOS Configuration feature with .DAT less solution. 34. Fixed after use AMIBCP tool to modify the "Restore on AC Power Loss" item and check the setting in the setup menu will be change. > But still, push hard. Make them clean this up -- better documents, > posted automatically. They'll do it if they have the right > incentive. I complained a bit to tech support about not having the change logs online, I don't know that I have the leverage to do much more. Hopefully guys like you with your major purchases will have better luck twisting their arm. > You might consider having a look at > https://github.com/joyent/sdcboot. Cool, thanks for the pointer. > The BMC remote media (it's not really part of IPMI) is Yah, I know, it's one of the few places I'm not technically accurate, it's just easier to discuss in some circles if you don't make the distinction. > horrible and usually doesn't work; it also requires a lot of manual > intervention to use. I've had pretty good luck with remote media, but I suppose if the one time it happened to flake out on me was during the middle of flashing the BIOS that would kind of suck :(, so it's probably worth sticking a USB stick in. Thanks for the help? From jmealo at stringtheoryschools.com Thu Jul 11 14:01:19 2013 From: jmealo at stringtheoryschools.com (Jeffrey Mealo) Date: Thu, 11 Jul 2013 10:01:19 -0400 Subject: [OmniOS-discuss] [smartos-discuss] Supermicro BIOS updates In-Reply-To: <51DB73C7.70105@acm.org> References: <51DB73C7.70105@acm.org> Message-ID: Just to jump in on the Super Micro discussion there's a remotely exploitable uPNP library present in the BMC/IPMI. You cannot shut it off from the GUI or console. Hopefully one of these updates fixes that. If you have a separate management network, it's a non-issue, but for those of us with less than ideal setups for remote management, this poses a problem. I would recommend installing any BMC updates that come out if the change log indicates and update to the uPNP library. Jeffrey Mealo Director of Data and Accountability String Theory Schools The Bellevue - Suite 930 200 S. Broad St Philadelphia, PA 19102 (215) 334-4222 x111 On Mon, Jul 8, 2013 at 10:21 PM, Paul B. Henson wrote: > Sorry for two potentially OT supermicro posts in a row :), I just know > they are really popular for illumos servers and there's such a wealth of > knowledge on these mailing lists. > > I usually update firmware/BIOS on a fairly regular basis on my servers, > but supermicro has a fairly scary warning on their download page: > > ------ > WARNING! > Please do not download / upgrade the BIOS/Firmware UNLESS your system has > a BIOS/firmware-related issue. Flashing the wrong BIOS/firmware can cause > irreparable damage to the system. > > In no event shall Supermicro be liable for direct, indirect, special, > incidental, or consequential damages arising from a BIOS/firmware update. > ------ > > Where it seems they pretty much do not want you to ever update unless you > know of a specific issue the update will solve. Of course, they also don't > post changelogs with their bios updates, so it's kind of hard to know 8-/. > I can't remember the last time I had a box die due to a corrupted bios > update (most of the ones I've worked with won't even let you try to flash > the wrong firmware), I was wondering if that's a problem with supermicro > boards to the point where they actively discourage updates? > > Their technical support sent me a changelog for the motherboard I'm > working with upon request (seems like it would be a timesaver for them to > just post it in the first place), and I think I do want to go ahead and > update the bios. I haven't had to boot DOS for a bios update in a *long* > time, my workstations for years have supported just sticking in a USB flash > drive with the image on it and updating from the bios itself, and the > servers I've been using supported bios updates via the IPMI web interface > or CLI. What's the preferred way to generate a bootable DOS image with the > bios update utility and image on it nowadays? I was thinking of just > downloading a freeDOS floppy image, loopback mounting it to copy on the > additional files, and then booting it via the IPMI remote media option. Is > there an easier way? > > Thanks much? > > > ------------------------------**------------- > smartos-discuss > Archives: https://www.listbox.com/**member/archive/184463/=now > RSS Feed: https://www.listbox.com/**member/archive/rss/184463/** > 24425453-7d3820db > Modify Your Subscription: https://www.listbox.com/** > member/?member_id=24425453&id_**secret=24425453-240156fc > Powered by Listbox: http://www.listbox.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.siden at delphix.com Thu Jul 11 20:15:45 2013 From: christopher.siden at delphix.com (Christopher Siden) Date: Thu, 11 Jul 2013 13:15:45 -0700 Subject: [OmniOS-discuss] 64/libjvm_db.so in runtime/java on bloody does not seem to be built correctly, pstack doesn't work Message-ID: Hi, I was recently playing around with the OpenJDK build in the bloody repo and noticed that pstack was only able to resolve Java stack frames when I used the 32-bit binary (/usr/bin/i86/pstack): fa00f402 * java/lang/Thread.sleep(J)V+0 fa00367b * org/apache/tomcat/util/net/JIoEndpoint$AsyncTimeout.run()V+13 (line 294) But the 64-bit pstack binary (/usr/bin/amd64/pstack) just prints question marks instead of class and method names: fa0f08a6 ???????? (85f4a28, 0, 858a778, 0, 0, 0) fa0fae7c ???????? (0, a4d, 0, 4c3, 0, 9ca8ab8f) Looking at the code in illumos's pstack.c it seems like pstack looks for a library called "libjvm.so" loaded into the target Java process, then looks for a library called "libjvm_db.so" in the same directory as libjvm.so and opens it with dlopen(3). libjvm_db.so provides pstack with the jvm-specific knowledge it needs to read java stack frames from the target process. When you are using a 64-bit pstack to debug a 32-bit java process it uses a special 64-bit version of the libjvm_db.so library stored in a sub directory called "64", the directory structure looks like this: /usr/java/lib/i386/server/libjvm.so /usr/java/lib/i386/server/libjvm_db.so /usr/java/lib/i386/server/64/libjvm_db.so Note that this 64-bit libjvm_db.so is still meant for debugging a 32-bit JVM, it's just compiled as a 64-bit library so that a 64-bit pstack process is capable of using it. The problem seems to be that the 64-bit version of libjvm_db.so in the runtime/java package in bloody right now is actually a 32-bit library: $ file /usr/java/lib/i386/server/64/libjvm_db.so /usr/java/lib/i386/server/64/libjvm_db.so: ELF 32-bit ... So the call to dlopen(3) from a 64-bit pstack process fails. The 32-bit Java 7 JDK distributed by Oracle does not have this problem: $ file /usr/java/jre/lib/i386/server/libjvm_db.so /usr/java/jre/lib/i386/server/libjvm_db.so: ELF 32-bit $ file /usr/java/jre/lib/i386/server/64/libjvm_db.so /usr/java/jre/lib/i386/server/64/libjvm_db.so: ELF 64-bit I was able to use both 64-bit and 32-bit pstack to see the Java stack frames of 32-bit Java processes running with Oracle's binaries. I downloaded and started building OpenJDK myself mimicing what it looks like the omni-build repository scripts do (I didn't run the scripts themselves). I let the build run until the 64-bit library was created and confirmed that it was in fact a 64-bit library: $ file ./build/solaris/solaris_i486_compiler2/product/libjvm_db.so ./build/solaris/solaris_i486_compiler2/product/libjvm_db.so: ELF 32-bit $ file ./build/solaris/solaris_i486_compiler2/product/64/libjvm_db.so ./build/solaris/solaris_i486_compiler2/product/64/libjvm_db.so: ELF 64-bit This seems like there is a problem with the way the 64-bit libjvm_db.so files currently in the runtime/java package were built, but I'm not familiar with how OmniTI builds those packages. Could it be they were built on a 32-bit system or something? Otherwise there might be some difference between OpenJDK and whatever repo Oracle bases their builds on? Thanks, Chris From daleg at omniti.com Thu Jul 11 21:55:22 2013 From: daleg at omniti.com (Dale Ghent) Date: Thu, 11 Jul 2013 17:55:22 -0400 Subject: [OmniOS-discuss] 64/libjvm_db.so in runtime/java on bloody does not seem to be built correctly, pstack doesn't work In-Reply-To: References: Message-ID: Thanks for reporting this. It does seem that when openjdk builds the binary tree, it does put the 32bit object in the location where the 64bit one should be. Why it's doing this is unknown to me after a quick glance at things, so we'll need to dig in and find out. /dale On Jul 11, 2013, at 4:15 PM, Christopher Siden wrote: > Hi, > I was recently playing around with the OpenJDK build in the bloody > repo and noticed that pstack was only able to resolve Java stack > frames when I used the 32-bit binary (/usr/bin/i86/pstack): > > fa00f402 * java/lang/Thread.sleep(J)V+0 > fa00367b * org/apache/tomcat/util/net/JIoEndpoint$AsyncTimeout.run()V+13 > (line 294) > > But the 64-bit pstack binary (/usr/bin/amd64/pstack) just prints > question marks instead of class and method names: > > fa0f08a6 ???????? (85f4a28, 0, 858a778, 0, 0, 0) > fa0fae7c ???????? (0, a4d, 0, 4c3, 0, 9ca8ab8f) > > Looking at the code in illumos's pstack.c it seems like pstack looks > for a library called "libjvm.so" loaded into the target Java process, > then looks for a library called "libjvm_db.so" in the same directory > as libjvm.so and opens it with dlopen(3). libjvm_db.so provides pstack > with the jvm-specific knowledge it needs to read java stack frames > from the target process. When you are using a 64-bit pstack to debug a > 32-bit java process it uses a special 64-bit version of the > libjvm_db.so library stored in a sub directory called "64", the > directory structure looks like this: > > /usr/java/lib/i386/server/libjvm.so > /usr/java/lib/i386/server/libjvm_db.so > /usr/java/lib/i386/server/64/libjvm_db.so > > Note that this 64-bit libjvm_db.so is still meant for debugging a > 32-bit JVM, it's just compiled as a 64-bit library so that a 64-bit > pstack process is capable of using it. > > The problem seems to be that the 64-bit version of libjvm_db.so in the > runtime/java package in bloody right now is actually a 32-bit library: > > $ file /usr/java/lib/i386/server/64/libjvm_db.so > /usr/java/lib/i386/server/64/libjvm_db.so: ELF 32-bit ... > > So the call to dlopen(3) from a 64-bit pstack process fails. The > 32-bit Java 7 JDK distributed by Oracle does not have this problem: > > $ file /usr/java/jre/lib/i386/server/libjvm_db.so > /usr/java/jre/lib/i386/server/libjvm_db.so: ELF 32-bit > $ file /usr/java/jre/lib/i386/server/64/libjvm_db.so > /usr/java/jre/lib/i386/server/64/libjvm_db.so: ELF 64-bit > > I was able to use both 64-bit and 32-bit pstack to see the Java stack > frames of 32-bit Java processes running with Oracle's binaries. > > I downloaded and started building OpenJDK myself mimicing what it > looks like the omni-build repository scripts do (I didn't run the > scripts themselves). I let the build run until the 64-bit library was > created and confirmed that it was in fact a 64-bit library: > > $ file ./build/solaris/solaris_i486_compiler2/product/libjvm_db.so > ./build/solaris/solaris_i486_compiler2/product/libjvm_db.so: ELF 32-bit > $ file ./build/solaris/solaris_i486_compiler2/product/64/libjvm_db.so > ./build/solaris/solaris_i486_compiler2/product/64/libjvm_db.so: ELF 64-bit > > This seems like there is a problem with the way the 64-bit > libjvm_db.so files currently in the runtime/java package were built, > but I'm not familiar with how OmniTI builds those packages. Could it > be they were built on a 32-bit system or something? Otherwise there > might be some difference between OpenJDK and whatever repo Oracle > bases their builds on? > > Thanks, > Chris > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From henson at acm.org Fri Jul 12 02:18:18 2013 From: henson at acm.org (Paul B. Henson) Date: Thu, 11 Jul 2013 19:18:18 -0700 Subject: [OmniOS-discuss] [smartos-discuss] Supermicro BIOS updates In-Reply-To: References: <51DB73C7.70105@acm.org> Message-ID: <51DF676A.5020501@acm.org> On 7/11/2013 7:01 AM, Jeffrey Mealo wrote: > from the GUI or console. Hopefully one of these updates fixes that. If > you have a separate management network, it's a non-issue, but for those > of us with less than ideal setups for remote management, this poses a > problem. I would recommend installing any BMC updates that come out if > the change log indicates and update to the uPNP library. It's not wise in general to expose these type of management devices to potentially malicious traffic. One time our ISO group got our network group to modify the ACL's on our management subnet without routing it through us and proceeded to do a full vulnerability scan 8-/. It was mostly Sun equipment of the x4100 line; in addition to pretty much hosing most of the SP's, it actually took out some of the servers themselves . Our ISO group is always fun to deal with? From cardenas12 at gmail.com Sun Jul 14 22:52:52 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Sun, 14 Jul 2013 15:52:52 -0700 Subject: [OmniOS-discuss] Switching to OpenSSH Message-ID: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> Greetings, I'm setting up OmniOS on a new machine and wanted to see how can I use the openssh pkg instead of the illumos version. I'm getting errors about openssh conflicting with ssh and how entire is dependent on it. -- Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From esproul at omniti.com Mon Jul 15 13:48:34 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 15 Jul 2013 09:48:34 -0400 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> Message-ID: On Sun, Jul 14, 2013 at 6:52 PM, Carlos Cardenas wrote: > Greetings, > > I'm setting up OmniOS on a new machine and wanted to see how can I use the > openssh pkg instead of the illumos version. > > I'm getting errors about openssh conflicting with ssh and how entire is > dependent on it. Hi Carlos, This is very much a work-in-progress. As I'm writing, I realize that we don't have a ticket for it (there is an internal OmniTI task open, but it should be transferred to an OmniOS ticket.) The packaging situation is less important than discovering whether stock OpenSSH is an acceptable drop-in replacement for SunSSH. I would love to see more people take a crack at running the stock version in their environments so we can find out how well it works (or doesn't). SunSSH is pretty deeply embedded within illumos-gate, and I think the biggest obstacle to updating or replacing it is the (apparent) lack of qualified people to evaluate the ramifications of any changes to, e.g. the privsep model, which is the biggest difference from upstream OpenSSH. Eric From esproul at omniti.com Mon Jul 15 14:03:44 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 15 Jul 2013 10:03:44 -0400 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> Message-ID: http://omnios.omniti.com/ticket.php/63 is now open to track OpenSSH work. From cardenas12 at gmail.com Mon Jul 15 17:22:12 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Mon, 15 Jul 2013 10:22:12 -0700 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> Message-ID: <9DA1117C758B40CEB2A30F33FDB36B8E@gmail.com> Thanks Eric. For the interim, I bootstrapped pkgsrc 2013Q2 and am running OpenSSH 6.2 from there (something I'm more familiar with ;-) ). Will wait for the fix to have this supported in the base system. -- Carlos On Monday, July 15, 2013 at 7:03 AM, Eric Sproul wrote: > http://omnios.omniti.com/ticket.php/63 is now open to track OpenSSH work. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com (mailto:OmniOS-discuss at lists.omniti.com) > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From esproul at omniti.com Mon Jul 15 17:33:30 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 15 Jul 2013 13:33:30 -0400 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: <9DA1117C758B40CEB2A30F33FDB36B8E@gmail.com> References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> <9DA1117C758B40CEB2A30F33FDB36B8E@gmail.com> Message-ID: On Mon, Jul 15, 2013 at 1:22 PM, Carlos Cardenas wrote: > Thanks Eric. > > For the interim, I bootstrapped pkgsrc 2013Q2 and am running OpenSSH 6.2 > from there (something I'm more familiar with ;-) ). > > Will wait for the fix to have this supported in the base system. Does it work for all your use cases? Are you using the new sandbox type of privsep (UsePrivilegeSeparation=sandbox)? From henson at acm.org Mon Jul 15 18:12:38 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 15 Jul 2013 11:12:38 -0700 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> Message-ID: <51E43B96.3070706@acm.org> On 7/15/2013 6:48 AM, Eric Sproul wrote: > The packaging situation is less important than discovering whether > stock OpenSSH is an acceptable drop-in replacement for SunSSH. I > would love to see more people take a crack at running the stock > version in their environments so we can find out how well it works (or > doesn't). SunSSH is pretty deeply embedded within illumos-gate, and I > think the biggest obstacle to updating or replacing it is the > (apparent) lack of qualified people to evaluate the ramifications of > any changes to, e.g. the privsep model, which is the biggest > difference from upstream OpenSSH. The openbsd crew has a pretty good reputation on security; I'm not sure what issues the portability layer might lay on top of the native privilege separation model, but I still think I'd rather go with "actively maintained" over "about as dead as a doornail" ;). Are you guys thinking about it some point dropping SunSSH from omnios and bundling in standard OpenSSH? I'd definitely be a +1 on that :), sunssh has been falling by the wayside as openssh continues to introduce new features, and it's annoying to have disparity between illumos based servers and my other boxes. As far as upstream, do you think it would be better to try and get them to swap out sunssh for openssh too, or maybe it would be better to just drop ssh completely from illumos-gate and have that be a distribution add-on like other user space utilities? From esproul at omniti.com Mon Jul 15 18:31:08 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 15 Jul 2013 14:31:08 -0400 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: <51E43B96.3070706@acm.org> References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> <51E43B96.3070706@acm.org> Message-ID: On Mon, Jul 15, 2013 at 2:12 PM, Paul B. Henson wrote: > The openbsd crew has a pretty good reputation on security; I'm not sure what > issues the portability layer might lay on top of the native privilege > separation model, but I still think I'd rather go with "actively maintained" > over "about as dead as a doornail" ;). No question about that. The only issue in my mind is whether the "actively maintained" piece is the standard, upstream portable OpenSSH or a resurrected SunSSH (because we require it for some reason) that is actively kept up within some reasonable tolerance to the upstream version. > > Are you guys thinking about it some point dropping SunSSH from omnios and > bundling in standard OpenSSH? I'd definitely be a +1 on that :), sunssh has > been falling by the wayside as openssh continues to introduce new features, > and it's annoying to have disparity between illumos based servers and my > other boxes. > > As far as upstream, do you think it would be better to try and get them to > swap out sunssh for openssh too, or maybe it would be better to just drop > ssh completely from illumos-gate and have that be a distribution add-on like > other user space utilities? I think if we can demonstrate that upstream OpenSSH "just works" as a replacement for SunSSH, that would bolster the effort to remove it from illumos-gate. I'm not sure what other obstacles may lurk there (integration with other major subsystems, like internationalization maybe.) That's why I'd like to encourage others to try it on their OmniOS systems. I'm fairly confident the typical login-for-remote-access will work fine-- it's the other, more esoteric, use cases that I haven't thought of that I'm not sure about. Eric From henson at acm.org Mon Jul 15 19:59:37 2013 From: henson at acm.org (Paul B. Henson) Date: Mon, 15 Jul 2013 12:59:37 -0700 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> <51E43B96.3070706@acm.org> Message-ID: <51E454A9.9070405@acm.org> On 7/15/2013 11:31 AM, Eric Sproul wrote: > from illumos-gate. I'm not sure what other obstacles may lurk there > (integration with other major subsystems, like internationalization > maybe.) From what I recall, the differences between openssh and sunssh were: * privilege separation (I don't think there's any technical reason why one approach works better on Solaris than the other, or that one couldn't be dropped in to replace the other, it was more a matter of the Sun folk at the time didn't like the openssh approach) * locale - sunssh supports language negotiation as defined in RFC 4253, I'm not sure if openssh does yet * sunssh is integrated into the Solaris auditing framework * sunssh uses the Solaris cryptographic framework rather than openssl, which historically gave it access to hardware acceleration that openssh didn't use, but I think openssl supports the same framework now I think the only real killer would be the auditing support, if somebody was leveraging that. From tim at multitalents.net Mon Jul 15 21:15:51 2013 From: tim at multitalents.net (Tim Rice) Date: Mon, 15 Jul 2013 14:15:51 -0700 (PDT) Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: <51E454A9.9070405@acm.org> References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> <51E43B96.3070706@acm.org> <51E454A9.9070405@acm.org> Message-ID: On Mon, 15 Jul 2013, Paul B. Henson wrote: > * sunssh is integrated into the Solaris auditing framework > > * sunssh uses the Solaris cryptographic framework rather than openssl, which > historically gave it access to hardware acceleration that openssh didn't use, > but I think openssl supports the same framework now > > I think the only real killer would be the auditing support, if somebody was > leveraging that. Back in the OpenSSH 4.0 days we see this in the ChangeLog 20050220 - (dtucker) [LICENCE Makefile.in README.platform audit-bsm.c configure.ac defines.h] Bug #125: Add *EXPERIMENTAL* BSM audit support. Configure --with-audit=bsm to enable. Patch originally from Sun Microsystems, parts by John R. Jackson. ok djm@ We're on 6.2 now. Let us know if something is not working right. -- Tim Rice Multitalents tim at multitalents.net From cardenas12 at gmail.com Tue Jul 16 02:08:52 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Mon, 15 Jul 2013 19:08:52 -0700 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> <51E43B96.3070706@acm.org> <51E454A9.9070405@acm.org> Message-ID: OpenSSH 6.2p1 + HPN patches from 2013Q2 (http://pkgsrc.joyent.com/packages/SmartOS/2013Q2/x86_64) Looking at the pkgsrc source for security/openssh, the patches that are there are for Interix, which tells me OpenSSH should be just fine in illumos. (IMO, It might be good to incorporate the HPN patches for performance reasons) By default from pkgsrc, the privsep model is sandbox and seems to be working fine. I haven't tested the auditing support; will do that later in the week as time permits. -- Carlos On Monday, July 15, 2013 at 2:15 PM, Tim Rice wrote: > On Mon, 15 Jul 2013, Paul B. Henson wrote: > > > * sunssh is integrated into the Solaris auditing framework > > > > * sunssh uses the Solaris cryptographic framework rather than openssl, which > > historically gave it access to hardware acceleration that openssh didn't use, > > but I think openssl supports the same framework now > > > > I think the only real killer would be the auditing support, if somebody was > > leveraging that. > > > > > Back in the OpenSSH 4.0 days we see this in the ChangeLog > 20050220 > - (dtucker) [LICENCE Makefile.in (http://Makefile.in) README.platform audit-bsm.c configure.ac (http://configure.ac) > defines.h] Bug #125: Add *EXPERIMENTAL* BSM audit support. Configure > --with-audit=bsm to enable. Patch originally from Sun Microsystems, > parts by John R. Jackson. ok djm@ > > We're on 6.2 now. > Let us know if something is not working right. > > -- > Tim Rice Multitalents > tim at multitalents.net (mailto:tim at multitalents.net) > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com (mailto:OmniOS-discuss at lists.omniti.com) > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cardenas12 at gmail.com Tue Jul 16 02:14:30 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Mon, 15 Jul 2013 19:14:30 -0700 Subject: [OmniOS-discuss] Build environment Message-ID: I'm trying to get my toughbook's wifi to work (I think the iwp doesn't have the PCI ids for the 6205) which I'm hoping is an easy fix. I have all pkgs installed, omnios-build cloned (I'm running the latest stable release: b281e50) and when I attempt to run `buildcntl list` it errors out saying I need to install gcc48, which is not in stable's repo. Do I need to be on bloody using bloody repos? Thanks in advance. -- Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From garrett.damore at dey-sys.com Mon Jul 15 21:01:43 2013 From: garrett.damore at dey-sys.com (Garrett D'Amore) Date: Mon, 15 Jul 2013 14:01:43 -0700 Subject: [OmniOS-discuss] Switching to OpenSSH In-Reply-To: <51E454A9.9070405@acm.org> References: <9F382E66FD6941128EBCBE53A0EE2F26@gmail.com> <51E43B96.3070706@acm.org> <51E454A9.9070405@acm.org> Message-ID: <74C4656A-4F43-4353-8DC8-25F966C10AF8@dey-sys.com> On Jul 15, 2013, at 12:59 PM, "Paul B. Henson" wrote: > On 7/15/2013 11:31 AM, Eric Sproul wrote: > >> from illumos-gate. I'm not sure what other obstacles may lurk there >> (integration with other major subsystems, like internationalization >> maybe.) > > From what I recall, the differences between openssh and sunssh were: > > * privilege separation (I don't think there's any technical reason why one approach works better on Solaris than the other, or that one couldn't be dropped in to replace the other, it was more a matter of the Sun folk at the time didn't like the openssh approach) The openssh approach didn't integrate well, IIRC, with Sun PAM, and I think privsep was part of the problem. > > * locale - sunssh supports language negotiation as defined in RFC 4253, I'm not sure if openssh does yet > > * sunssh is integrated into the Solaris auditing framework > > * sunssh uses the Solaris cryptographic framework rather than openssl, which historically gave it access to hardware acceleration that openssh didn't use, but I think openssl supports the same framework now Actually, I'm pretty sure that sunssh was relying on Sun's openssl port to get this. I don't think sunssh calls directly into the crypto framework. (Could be mistaken, of course.) > > I think the only real killer would be the auditing support, if somebody was leveraging that. That's probably a show-stopper. I'd be very careful to make sure that OpenSSH works properly with Sun's PAM support. Probably that's where the auditing support is required as well. - Garrett > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From cnehren+omnios-discuss at omniti.com Tue Jul 16 02:33:03 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Mon, 15 Jul 2013 22:33:03 -0400 Subject: [OmniOS-discuss] Build environment In-Reply-To: References: Message-ID: <20130716023302.GS98158@eschaton.local> On Mon, Jul 15, 2013 at 19:14:30 -0700 , Carlos Cardenas wrote: > I'm trying to get my toughbook's wifi to work (I think the iwp doesn't have > the PCI ids for the 6205) which I'm hoping is an easy fix. > > I have all pkgs installed, omnios-build cloned (I'm running the latest > stable release: b281e50) and when I attempt to run `buildcntl list` it > errors out saying I need to install gcc48, which is not in stable's repo. Do > I need to be on bloody using bloody repos? No, you do not need to be on bloody to build things from omnios-build. You should check out the branch for the release you're on (cat /etc/release) and build there. That way you're building the bits that you're running. -- Chris Nehren Site Reliability Engineer, OmniTI From cardenas12 at gmail.com Tue Jul 16 02:38:06 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Mon, 15 Jul 2013 19:38:06 -0700 Subject: [OmniOS-discuss] Build environment In-Reply-To: <20130716023302.GS98158@eschaton.local> References: <20130716023302.GS98158@eschaton.local> Message-ID: Thanks Chris. -- Carlos On Monday, July 15, 2013 at 7:33 PM, Chris Nehren wrote: > On Mon, Jul 15, 2013 at 19:14:30 -0700 , Carlos Cardenas wrote: > > I'm trying to get my toughbook's wifi to work (I think the iwp doesn't have > > the PCI ids for the 6205) which I'm hoping is an easy fix. > > > > I have all pkgs installed, omnios-build cloned (I'm running the latest > > stable release: b281e50) and when I attempt to run `buildcntl list` it > > errors out saying I need to install gcc48, which is not in stable's repo. Do > > I need to be on bloody using bloody repos? > > > > > No, you do not need to be on bloody to build things from omnios-build. > You should check out the branch for the release you're on (cat > /etc/release) and build there. That way you're building the bits that > you're running. > > -- > Chris Nehren > Site Reliability Engineer, OmniTI > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com (mailto:OmniOS-discuss at lists.omniti.com) > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cardenas12 at gmail.com Tue Jul 16 02:47:26 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Mon, 15 Jul 2013 19:47:26 -0700 Subject: [OmniOS-discuss] Switching syslog with rsyslog Message-ID: <12FA49CA183D4402B05F59DC62C29A53@gmail.com> Has anyone switched syslog with rsyslog? In particular, I would like to use rsyslog 7.4.0, esp log signing with Guardtime: http://blog.gerhards.net/2013/05/rsyslogs-first-signature-provider-why.html . If not, is there anything more substantial than http://omnios.omniti.com/wiki.php/PackagingForOmniOS for creating new pkgs? -- Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnehren+omnios-discuss at omniti.com Tue Jul 16 03:05:25 2013 From: cnehren+omnios-discuss at omniti.com (Chris Nehren) Date: Mon, 15 Jul 2013 23:05:25 -0400 Subject: [OmniOS-discuss] Switching syslog with rsyslog In-Reply-To: <12FA49CA183D4402B05F59DC62C29A53@gmail.com> References: <12FA49CA183D4402B05F59DC62C29A53@gmail.com> Message-ID: <20130716030524.GU98158@eschaton.local> On Mon, Jul 15, 2013 at 19:47:26 -0700 , Carlos Cardenas wrote: > Has anyone switched syslog with rsyslog? Yes, in at least one of our environments. > In particular, I would like to use rsyslog 7.4.0, esp log signing with > Guardtime: > http://blog.gerhards.net/2013/05/rsyslogs-first-signature-provider-why.html > . I don't think we've tried this configuration, though. > If not, is there anything more substantial than > http://omnios.omniti.com/wiki.php/PackagingForOmniOS for creating new pkgs? It sounds like you're wanting to package rsyslog. That's unnecessary: we already have a package in the ms.omniti.com repository, documented at e.g. http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfigurePublishers and http://omnios.omniti.com/wiki.php/Packaging . -- Chris Nehren Site Reliability Engineer, OmniTI From cardenas12 at gmail.com Tue Jul 16 03:35:34 2013 From: cardenas12 at gmail.com (cardenas12 at gmail.com) Date: Mon, 15 Jul 2013 20:35:34 -0700 (PDT) Subject: [OmniOS-discuss] Switching syslog with rsyslog In-Reply-To: <20130716030524.GU98158@eschaton.local> References: <12FA49CA183D4402B05F59DC62C29A53@gmail.com> <20130716030524.GU98158@eschaton.local> Message-ID: <51e4bf86.8358440a.1473.385f@mx.google.com> An HTML attachment was scrubbed... URL: From esproul at omniti.com Tue Jul 16 13:35:15 2013 From: esproul at omniti.com (Eric Sproul) Date: Tue, 16 Jul 2013 09:35:15 -0400 Subject: [OmniOS-discuss] Switching syslog with rsyslog In-Reply-To: <51e4bf86.8358440a.1473.385f@mx.google.com> References: <12FA49CA183D4402B05F59DC62C29A53@gmail.com> <20130716030524.GU98158@eschaton.local> <51e4bf86.8358440a.1473.385f@mx.google.com> Message-ID: On Mon, Jul 15, 2013 at 11:35 PM, wrote: > That's awesome Chris, where can I find the package source so I can update > to the latest stable version? GitHub or somewhere else? > The build scripts for ms.omniti.com packages are in the omniti-ms branch of omnios-build: https://github.com/omniti-labs/omnios-build/tree/omniti-ms -------------- next part -------------- An HTML attachment was scrubbed... URL: From cardenas12 at gmail.com Tue Jul 16 18:12:36 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Tue, 16 Jul 2013 11:12:36 -0700 Subject: [OmniOS-discuss] Switching syslog with rsyslog In-Reply-To: References: <12FA49CA183D4402B05F59DC62C29A53@gmail.com> <20130716030524.GU98158@eschaton.local> <51e4bf86.8358440a.1473.385f@mx.google.com> Message-ID: <250C5563A9C74B918C8B152090616C2A@gmail.com> I'll send an PR later this week{end}. -- Carlos On Tuesday, July 16, 2013 at 6:35 AM, Eric Sproul wrote: > > > > On Mon, Jul 15, 2013 at 11:35 PM, wrote: > > That's awesome Chris, where can I find the package source so I can update to the latest stable version? GitHub or somewhere else? > > The build scripts for ms.omniti.com (http://ms.omniti.com) packages are in the omniti-ms branch of omnios-build: https://github.com/omniti-labs/omnios-build/tree/omniti-ms > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com (mailto:OmniOS-discuss at lists.omniti.com) > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daleg at omniti.com Wed Jul 17 20:10:41 2013 From: daleg at omniti.com (Dale Ghent) Date: Wed, 17 Jul 2013 16:10:41 -0400 Subject: [OmniOS-discuss] Updated release: r151006l Message-ID: <7BA1151A-35C5-45D6-A3B0-5A13BC7A9C1D@omniti.com> This week brings a new release: r151006l This release entails only a security fix for library/libxml2, updating its version from 2.9.0 to 2.9.1. Full release notes are available here: http://omnios.omniti.com/wiki.php/ReleaseNotes#r151006l As this is an update which addresses a security issue, fresh r151006l install media has been generated: http://omnios.omniti.com/wiki.php/Installation /dale -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.oltman at gmail.com Wed Jul 17 22:02:05 2013 From: jim.oltman at gmail.com (Jim Oltman) Date: Wed, 17 Jul 2013 17:02:05 -0500 Subject: [OmniOS-discuss] SuperMicro IPMI Keyboard Message-ID: I'm trying to load the OmniOS ISO (OmniOS_Text_r151006l.iso) through the Virtual Media on my SuperMicro board (X8STi-F). The ISO loads fine, but when I attempt to use my keyboard to type in the Keyboard Layout, I'm getting $& (instead of 47). I can't find any settings to change this in the IPMI config, and was wondering if others have seen this issue. Thanks! Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Thu Jul 18 04:28:32 2013 From: henson at acm.org (Paul B. Henson) Date: Wed, 17 Jul 2013 21:28:32 -0700 Subject: [OmniOS-discuss] SuperMicro IPMI Keyboard In-Reply-To: References: Message-ID: <20130718042832.GY15578@bender.unx.csupomona.edu> On Wed, Jul 17, 2013 at 05:02:05PM -0500, Jim Oltman wrote: > I'm trying to load the OmniOS ISO (OmniOS_Text_r151006l.iso) through the > Virtual Media on my SuperMicro board (X8STi-F). The ISO loads fine, but > when I attempt to use my keyboard to type in the Keyboard Layout, I'm > getting $& (instead of 47). I can't find any settings to change this in > the IPMI config, and was wondering if others have seen this issue. Thanks! I've used the java remote head/media app to install omnios on an X9SRI-F based server with no problem. Almost looks like you have a stuck shift key? If you break into grub while it's booting is the keyboard messed up there too? From reh at hebis.uni-frankfurt.de Thu Jul 18 07:15:07 2013 From: reh at hebis.uni-frankfurt.de (Uwe Reh) Date: Thu, 18 Jul 2013 09:15:07 +0200 Subject: [OmniOS-discuss] SuperMicro IPMI Keyboard In-Reply-To: References: Message-ID: <51E795FB.1080409@hebis.uni-frankfurt.de> Hi this is a Supermicro issue. I have similar experiences with OI, S11 and several linux distributions. I'm using the KVM-Console with several Supermicroboards and different Versions of Java on Windows. None of this combinations is perfect. Sometimes it helps to use a 'wrong' layout of the keyboard. (German vs. English layout) But most of the time one or two Keys remain inaccessible. For them I'm using the virtual keybord of the KVM-Applet. It's ugly, but it works. Uwe Am 18.07.2013 00:02, schrieb Jim Oltman: > I'm trying to load the OmniOS ISO (OmniOS_Text_r151006l.iso) through the > Virtual Media on my SuperMicro board (X8STi-F). The ISO loads fine, but > when I attempt to use my keyboard to type in the Keyboard Layout, I'm > getting $& (instead of 47). I can't find any settings to change this in > the IPMI config, and was wondering if others have seen this issue. Thanks! > > Jim > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From bill.rees at tegile.com Wed Jul 17 22:27:54 2013 From: bill.rees at tegile.com (Bill Rees) Date: Wed, 17 Jul 2013 15:27:54 -0700 Subject: [OmniOS-discuss] bug tracking Message-ID: Is there an external interface to the bug tracking system? Thanks, Bill Rees -------------- next part -------------- An HTML attachment was scrubbed... URL: From daleg at omniti.com Thu Jul 18 14:32:16 2013 From: daleg at omniti.com (Dale Ghent) Date: Thu, 18 Jul 2013 10:32:16 -0400 Subject: [OmniOS-discuss] bug tracking In-Reply-To: References: Message-ID: On Jul 17, 2013, at 6:27 PM, Bill Rees wrote: > Is there an external interface to the bug tracking system? Are you looking for this? http://omnios.omniti.com/query.php /dale From jim.oltman at gmail.com Thu Jul 18 16:29:57 2013 From: jim.oltman at gmail.com (Jim Oltman) Date: Thu, 18 Jul 2013 11:29:57 -0500 Subject: [OmniOS-discuss] customizing rpool for iso install In-Reply-To: <516F5FA6.7080908@acm.org> References: <516F5FA6.7080908@acm.org> Message-ID: On Wed, Apr 17, 2013 at 9:51 PM, Paul B. Henson wrote: > While the recommended way to customize rpool configuration is to utilize a > network install with kayak, putting together a complete dhcp/tftp/http > network install environment is a bit overkill for installing one box or > doing some testing. > > So, instead I hacked together a little perl script (attached) that > interposes itself between the installer and the zpool creation allowing > some basic customizations while doing an iso install. > > Boot the installer media, and pick option 3/shell prior to beginning the > install. Get the attached script into /tmp one way or another (light up the > network interface and suck it over with wget, for example) and make it > executable. Run it, and it will copy the zpool/zfs binaries into /tmp and > install itself in their place with an overlay mount. > > Edit the script to configure what customizations you might want to make. > The first option is if you want to use less than the entire disk for the > rpool. If enabled, s0 on the installation device will be modified to the > size specified. The second option allows you to provide any arbitrary zpool > options to the zpool create (for example, to enable compression). The last > two options allow you to specify the size of swap/dump explicitly rather > than using the installer generated values. > > Exit the shell and go back to the installer, and start the installation. > Proceed through as normal, and when it is done, the created rpool should > include the customizations you picked? > > If there's any interest, I could add this to the installation section of > the wiki; unless it's deemed too kludgy to advertise ;). Paul, I'm having issues with the script. It probably stems from me not knowing anything about scripting or OmniOS. I followed your directions and have set the script to executable. I run it: ./omnios_zpool_install.pl And I get this: mount: ./omnios_zpool_install.pl: Device busy mount: ./omnios_zpool_install.pl: Device busy The only thing I uncommented was the line: $rpool_size = '5gb'; As I wanted the installer to use the whole disk. Any pointers on what I'm doing wrong? Thanks! Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Thu Jul 18 19:10:48 2013 From: henson at acm.org (Paul B. Henson) Date: Thu, 18 Jul 2013 12:10:48 -0700 Subject: [OmniOS-discuss] customizing rpool for iso install In-Reply-To: References: <516F5FA6.7080908@acm.org> Message-ID: <51E83DB8.6020909@acm.org> On 7/18/2013 9:29 AM, Jim Oltman wrote: > ./omnios_zpool_install.pl > > And I get this: > > mount: ./omnios_zpool_install.pl > Device busy Hmm, my first guess is that the overlay mount the script executes uses the name the script was executed as and mount doesn't like the relative path. Try running it with a fully qualified path "/tmp/omnios_zpool_install.pl"; I updated the wiki to note this. From bill.rees at tegile.com Thu Jul 18 19:58:15 2013 From: bill.rees at tegile.com (Bill Rees) Date: Thu, 18 Jul 2013 12:58:15 -0700 Subject: [OmniOS-discuss] bug tracking In-Reply-To: References: Message-ID: Why, yes! Thanks. Bill On Thu, Jul 18, 2013 at 7:32 AM, Dale Ghent wrote: > On Jul 17, 2013, at 6:27 PM, Bill Rees wrote: > > > Is there an external interface to the bug tracking system? > > Are you looking for this? > > http://omnios.omniti.com/query.php > > /dale > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Thu Jul 18 22:48:05 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 19 Jul 2013 00:48:05 +0200 (CEST) Subject: [OmniOS-discuss] areca or lsi Message-ID: Folks, We are specing a new omnios server box ... and were just told by our vendor, that LSI HBAs were much slower (50%) than Areca Controllers running in JBOD mode ... and that they would therefore recommend Areca (we use areca for raid6 in linux boxes, but have never used it in JBOD mode with illumos, yet). Which controller would you choose for a new system ? cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From fabio at fabiorabelo.wiki.br Thu Jul 18 22:55:20 2013 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Thu, 18 Jul 2013 19:55:20 -0300 Subject: [OmniOS-discuss] areca or lsi In-Reply-To: References: Message-ID: This is my guideline article in this subject : http://blog.zorinaq.com/?e=10 My box uses the IBM 1015 ones, works very good F?bio Rabelo 2013/7/18 Tobias Oetiker > Folks, > > We are specing a new omnios server box ... and were just told by > our vendor, that LSI HBAs were much slower (50%) than Areca Controllers > running in JBOD mode ... and that they would therefore recommend > Areca (we use areca for raid6 in linux boxes, but have never used it in > JBOD > mode with illumos, yet). > > Which controller would you choose for a new system ? > > cheers > tobi > > -- > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland > http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From turbo124 at gmail.com Thu Jul 18 23:02:49 2013 From: turbo124 at gmail.com (David Bomba) Date: Fri, 19 Jul 2013 09:02:49 +1000 Subject: [OmniOS-discuss] areca or lsi In-Reply-To: References: Message-ID: We use ARECA 1882 series cards in all our OmniOS storage servers. We moved from a Linux/GlusterFS environment to OmniOS/Comstar and our benchmarks have been very similar between the two using these controllers. I highly recommend them, they have been very reliable for us, and performance has been exceptional. On 19 July 2013 08:55, F?bio Rabelo wrote: > This is my guideline article in this subject : > > http://blog.zorinaq.com/?e=10 > > My box uses the IBM 1015 ones, works very good > > > F?bio Rabelo > > > 2013/7/18 Tobias Oetiker > >> Folks, >> >> We are specing a new omnios server box ... and were just told by >> our vendor, that LSI HBAs were much slower (50%) than Areca Controllers >> running in JBOD mode ... and that they would therefore recommend >> Areca (we use areca for raid6 in linux boxes, but have never used it in >> JBOD >> mode with illumos, yet). >> >> Which controller would you choose for a new system ? >> >> cheers >> tobi >> >> -- >> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland >> http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skiselkov.ml at gmail.com Fri Jul 19 00:03:52 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 19 Jul 2013 01:03:52 +0100 Subject: [OmniOS-discuss] areca or lsi In-Reply-To: References: Message-ID: <51E88268.8060507@gmail.com> On 18/07/2013 23:48, Tobias Oetiker wrote: > Folks, > > We are specing a new omnios server box ... and were just told by > our vendor, that LSI HBAs were much slower (50%) than Areca Controllers > running in JBOD mode ... and that they would therefore recommend > Areca (we use areca for raid6 in linux boxes, but have never used it in JBOD > mode with illumos, yet). > > Which controller would you choose for a new system ? Hi Tobi, I'm using LSI exclusively, never had an issue with them. Their 6G SAS HBAs are very affordable and remarkably solid. As for the ARECA vs LSI debate, I'd contest that there's going to be any appreciable performance difference. *IF* you're running in JBOD, the card should essentially be a simple pipe for SCSI commands to the SAS bus with as little overhead possible. I know for a fact that saturating a 6G SAS link isn't a problem with LSI cards, so I'm somewhat at a loss as to where the performance difference is supposed to lie. Cheers, -- Saso From turbo124 at gmail.com Fri Jul 19 02:05:05 2013 From: turbo124 at gmail.com (David Bomba) Date: Fri, 19 Jul 2013 12:05:05 +1000 Subject: [OmniOS-discuss] areca or lsi In-Reply-To: <51E88268.8060507@gmail.com> References: <51E88268.8060507@gmail.com> Message-ID: High quality RAID cards don't just perform simple passthrough, even thou we would expect this to be all that is needed in a ZFS implementation. The controller will (at least in Areca's case) utilise writeback caching to improve performance, driver implementation is also a major factor in performance. We've seen significant performance improvements with firmware upgrades on Areca cards. On 19 July 2013 10:03, Saso Kiselkov wrote: > On 18/07/2013 23:48, Tobias Oetiker wrote: > > Folks, > > > > We are specing a new omnios server box ... and were just told by > > our vendor, that LSI HBAs were much slower (50%) than Areca Controllers > > running in JBOD mode ... and that they would therefore recommend > > Areca (we use areca for raid6 in linux boxes, but have never used it in > JBOD > > mode with illumos, yet). > > > > Which controller would you choose for a new system ? > > Hi Tobi, > > I'm using LSI exclusively, never had an issue with them. Their 6G SAS > HBAs are very affordable and remarkably solid. As for the ARECA vs LSI > debate, I'd contest that there's going to be any appreciable performance > difference. *IF* you're running in JBOD, the card should essentially be > a simple pipe for SCSI commands to the SAS bus with as little overhead > possible. I know for a fact that saturating a 6G SAS link isn't a > problem with LSI cards, so I'm somewhat at a loss as to where the > performance difference is supposed to lie. > > Cheers, > -- > Saso > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Fri Jul 19 03:23:59 2013 From: chip at innovates.com (Schweiss, Chip) Date: Thu, 18 Jul 2013 22:23:59 -0500 Subject: [OmniOS-discuss] areca or lsi In-Reply-To: <51E88268.8060507@gmail.com> References: <51E88268.8060507@gmail.com> Message-ID: I have used LSI HBAs exclusively. Performance and reliability has been very good. The only problem I have consistently seen is if I hotplug a sas expander with or without disks attached it will crash the system at least half the time. I have simple resolved never doing that hot. I have stuck with LSI because of using LSI SAS expanders to keep the communication across venders to the minimum. The last thing I want is to be in the middle of finger pointing between venders. -Chip On Thu, Jul 18, 2013 at 7:03 PM, Saso Kiselkov wrote: > On 18/07/2013 23:48, Tobias Oetiker wrote: > > Folks, > > > > We are specing a new omnios server box ... and were just told by > > our vendor, that LSI HBAs were much slower (50%) than Areca Controllers > > running in JBOD mode ... and that they would therefore recommend > > Areca (we use areca for raid6 in linux boxes, but have never used it in > JBOD > > mode with illumos, yet). > > > > Which controller would you choose for a new system ? > > Hi Tobi, > > I'm using LSI exclusively, never had an issue with them. Their 6G SAS > HBAs are very affordable and remarkably solid. As for the ARECA vs LSI > debate, I'd contest that there's going to be any appreciable performance > difference. *IF* you're running in JBOD, the card should essentially be > a simple pipe for SCSI commands to the SAS bus with as little overhead > possible. I know for a fact that saturating a 6G SAS link isn't a > problem with LSI cards, so I'm somewhat at a loss as to where the > performance difference is supposed to lie. > > Cheers, > -- > Saso > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skiselkov.ml at gmail.com Fri Jul 19 09:29:19 2013 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Fri, 19 Jul 2013 10:29:19 +0100 Subject: [OmniOS-discuss] areca or lsi In-Reply-To: References: <51E88268.8060507@gmail.com> Message-ID: <51E906EF.3020407@gmail.com> On 19/07/2013 03:05, David Bomba wrote: > High quality RAID cards don't just perform simple passthrough, even thou > we would expect this to be all that is needed in a ZFS implementation. I know that that's what *RAID* cards do, but I specifically try to avoid RAID cards and go for simple HBAs. Hardware (and by that I also mean the firmware running on it) should be as dumb/simple as possible, I want to keep all of the complex logic in the software, which I can monitor (DTrace), update and fix myself if necessary. I've had plenty of performance issues on e.g. HP SmartArrays which just put a fat opaque layer between you and the drives and then it's anybody's guess on why the system's performance is sucking. > The controller will (at least in Areca's case) utilise writeback caching > to improve performance, driver implementation is also a major factor in > performance. We've seen significant performance improvements with > firmware upgrades on Areca cards. Here you've reiterated my point on the trouble of diagnosing performance. By simply swapping the driver you've seen "significant performance improvements", so good luck getting the driver vendor to optimize their driver if your customer is crying that performance is bad. Cheers, -- Saso From richard.elling at richardelling.com Fri Jul 19 22:54:52 2013 From: richard.elling at richardelling.com (Richard Elling) Date: Fri, 19 Jul 2013 15:54:52 -0700 Subject: [OmniOS-discuss] areca or lsi In-Reply-To: References: <51E88268.8060507@gmail.com> Message-ID: <62194D76-1B07-4DE8-80A1-25FF4B246D8C@RichardElling.com> On Jul 18, 2013, at 8:23 PM, "Schweiss, Chip" wrote: > I have used LSI HBAs exclusively. Performance and reliability has been very good. > > The only problem I have consistently seen is if I hotplug a sas expander with or without disks attached it will crash the system at least half the time. I have simple resolved never doing that hot. This was a known bug in the mptsas driver more than a year ago. The root cause was related to the driver trying to manage LEDs. IIRC, a fix was integrated upstream as part of a set of changes in May 2012. If your experience is with a later release, then please file a bug at illumos.org. -- richard > > I have stuck with LSI because of using LSI SAS expanders to keep the communication across venders to the minimum. The last thing I want is to be in the middle of finger pointing between venders. > > -Chip > > > On Thu, Jul 18, 2013 at 7:03 PM, Saso Kiselkov wrote: > On 18/07/2013 23:48, Tobias Oetiker wrote: > > Folks, > > > > We are specing a new omnios server box ... and were just told by > > our vendor, that LSI HBAs were much slower (50%) than Areca Controllers > > running in JBOD mode ... and that they would therefore recommend > > Areca (we use areca for raid6 in linux boxes, but have never used it in JBOD > > mode with illumos, yet). > > > > Which controller would you choose for a new system ? > > Hi Tobi, > > I'm using LSI exclusively, never had an issue with them. Their 6G SAS > HBAs are very affordable and remarkably solid. As for the ARECA vs LSI > debate, I'd contest that there's going to be any appreciable performance > difference. *IF* you're running in JBOD, the card should essentially be > a simple pipe for SCSI commands to the SAS bus with as little overhead > possible. I know for a fact that saturating a 6G SAS link isn't a > problem with LSI cards, so I'm somewhat at a loss as to where the > performance difference is supposed to lie. > > Cheers, > -- > Saso > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alka at hfg-gmuend.de Sat Jul 20 11:30:10 2013 From: alka at hfg-gmuend.de (=?ISO-8859-1?Q?G=FCnther_Alka?=) Date: Sat, 20 Jul 2013 13:30:10 +0200 Subject: [OmniOS-discuss] areca or lsi In-Reply-To: References: Message-ID: <51EA74C2.6010302@hfg-gmuend.de> I have build a lot of OmniOS boxes and was involved in a lot of hardware decisions. All of them are using LSI HBAs in raidless IT mode. If there was ever a consensus in the Solarish world regarding disk controller than this: - prefer pure HBAs, avoid hardware raid cards, use those with IT firmware - avoid controller cache, ZFS needs full disk control especially with sync write - your regular RAM, used by ZFS is anyway larger and faster - prefer LSI (nearly all Solarish ZFS boxes are using LSI) where you can expect the best driver quality My own favourite on OmniOS is the LSI 9207 with PCI-E 3.0 and the new 2308 chipset They come out of the box with the desired IT firmware, no need to reflash like with other LSI controllers. I would add: If you need expanders, use LSI ones paired with LSI HBAs, use SAS disks with expanders or if you intend to use Sata disks, prefer as much HBAs as needed without expander. Gea On 19.07.2013 00:48, Tobias Oetiker wrote: > Folks, > > We are specing a new omnios server box ... and were just told by > our vendor, that LSI HBAs were much slower (50%) than Areca Controllers > running in JBOD mode ... and that they would therefore recommend > Areca (we use areca for raid6 in linux boxes, but have never used it in JBOD > mode with illumos, yet). > > Which controller would you choose for a new system ? > > cheers > tobi > -- H f G Hochschule f?r Gestaltung university of design Schw?bisch Gm?nd Marie-Curie-Str. 19 73529 Schw?bisch Gm?nd Guenther Alka, Dipl.-Ing. (FH) Leiter des Rechenzentrums head of computer center Tel 07171 602 624 Fax 07171 69259 guenther.alka at hfg-gmuend.de http://rz.hfg-gmuend.de From cardenas12 at gmail.com Sun Jul 21 00:07:22 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Sat, 20 Jul 2013 17:07:22 -0700 Subject: [OmniOS-discuss] Switching syslog with rsyslog In-Reply-To: <250C5563A9C74B918C8B152090616C2A@gmail.com> References: <12FA49CA183D4402B05F59DC62C29A53@gmail.com> <20130716030524.GU98158@eschaton.local> <51e4bf86.8358440a.1473.385f@mx.google.com> <250C5563A9C74B918C8B152090616C2A@gmail.com> Message-ID: <982CC057AC1542D2B195B5658FB32D47@gmail.com> Ok? I have rsyslog 7.4.3 building/running with Guardtime enabled. As a result of jumping from 7.3.9 to 7.4.3, I had to add several new pkgs (deps): * libguardtime (Guardtime C SDK) * guardtime (Guardtime Client utility) * python26-docutils (build dep, generate man pages) I've also added rsyslog diag and user tools to allow for the additional functionality of using Guardtime within rsyslog. The one caveat I have with the latest rsyslog with GT support is that there is bug with the 64bit version of libguardtime linking with curl so rsyslog is 32bit. I'm opening a bug report with GT on this and hope to have this resolved soon. That said, is 32bit fine or do y'all want to wait until we have 64bit as well? How do y'all want the PRs done: all in one or one PR per pkg? Thanks in advance. -- Carlos On Tuesday, July 16, 2013 at 11:12 AM, Carlos Cardenas wrote: > I'll send an PR later this week{end}. > > -- > Carlos > > > On Tuesday, July 16, 2013 at 6:35 AM, Eric Sproul wrote: > > > > > > > > > On Mon, Jul 15, 2013 at 11:35 PM, wrote: > > > That's awesome Chris, where can I find the package source so I can update to the latest stable version? GitHub or somewhere else? > > > > The build scripts for ms.omniti.com (http://ms.omniti.com) packages are in the omniti-ms branch of omnios-build: https://github.com/omniti-labs/omnios-build/tree/omniti-ms > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com (mailto:OmniOS-discuss at lists.omniti.com) > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From itsmesyndicate at gmail.com Mon Jul 22 10:43:28 2013 From: itsmesyndicate at gmail.com (Rob Kruijt) Date: Mon, 22 Jul 2013 12:43:28 +0200 Subject: [OmniOS-discuss] php-54 from omniti Message-ID: Hi, I`ve got a little question, I`m using the following PHP package On my omios apache server. Name: omniti/runtime/php-54 Summary: PHP Server 5.4 Publisher: ms.omniti.com Version: 5.4.14 Build Release: 5.11 Branch: 0.151004 Packaging Date: Fri Apr 26 19:54:20 2013 Size: 40.01 MB FMRI: pkg://ms.omniti.com/omniti/runtime/php-54 at 5.4.14,5.11-0.151004:20130426T195420Z It works great, but now i need to edit the php.ini.... but its nowhere to be found? anyone have a clue ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From esproul at omniti.com Mon Jul 22 14:49:00 2013 From: esproul at omniti.com (Eric Sproul) Date: Mon, 22 Jul 2013 10:49:00 -0400 Subject: [OmniOS-discuss] php-54 from omniti In-Reply-To: References: Message-ID: Rob, Our PHP package doesn't ship a default .ini file, but you can find the config dir thusly: $ echo '' | /opt/php54/bin/php | grep '^Configuration File' Configuration File (php.ini) Path => /opt/php54/lib Place your php.ini file there, or configure Apache to look elsewhere with PHPIniDir Regards, Eric On Mon, Jul 22, 2013 at 6:43 AM, Rob Kruijt wrote: > Hi, > > I`ve got a little question, > I`m using the following PHP package On my omios apache server. > > > > Name: omniti/runtime/php-54 > Summary: PHP Server 5.4 > Publisher: ms.omniti.com > Version: 5.4.14 > Build Release: 5.11 > Branch: 0.151004 > Packaging Date: Fri Apr 26 19:54:20 2013 > Size: 40.01 MB > FMRI: > pkg://ms.omniti.com/omniti/runtime/php-54 at 5.4.14,5.11-0.151004:20130426T195420Z > > > It works great, but now i need to edit the php.ini.... but its nowhere to be > found? anyone have a clue ? > > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From peter at ifm.liu.se Mon Jul 22 20:16:23 2013 From: peter at ifm.liu.se (Peter Eriksson) Date: Mon, 22 Jul 2013 22:16:23 +0200 Subject: [OmniOS-discuss] Installing OmniOS on a X4500 via PXE? Message-ID: <926810C0-0CBF-4C7B-9E24-A065D9C821B0@ifm.liu.se> I've tried following the instructions in the Wiki on network-installing OmniOS on one of our Sun X4500 Thumpers but the kernel just panics and crashed at the boot stage. Has anyone else succeded in doing this before and have some pointers? (We PXE-boot from a Solaris 10 box). It works PXE-booting SmartOS on the same box - so I think it *should* work... :-) - Peter From seb.messier at gmail.com Tue Jul 23 00:58:42 2013 From: seb.messier at gmail.com (Sebastien Messier) Date: Mon, 22 Jul 2013 20:58:42 -0400 Subject: [OmniOS-discuss] Trying hard to compile par2cmdline and nzbget Message-ID: So i'm trying to build stuff for my omnios server and i can't compile nothing. This is the error i get when compiling nzbget *# make* */usr/bin/make all-am* *g++ -g -O2 -L/usr/lib -L/usr/lib -L/usr/lib -L/usr/lib -o nzbget ArticleDownloader.o BinRpc.o ColoredFrontend.o Connection.o Decoder.o DiskState.o DownloadInfo.o Frontend.o Log.o LoggableFrontend.o NCursesFrontend.o NNTPConnection.o NZBFile.o NewsServer.o Observer.o Options.o ParChecker.o ParRenamer.o ParCoordinator.o PrePostProcessor.o QueueCoordinator.o QueueEditor.o RemoteClient.o RemoteServer.o Scanner.o Scheduler.o ScriptController.o ServerPool.o svn_version.o TLS.o Thread.o Util.o XmlRpc.o WebDownloader.o WebServer.o UrlCoordinator.o Unpack.o nzbget.o -lz -lpar2 -lcurses -lresolv -lnsl -lsocket -lxml2 -lsigc-2.0 -lssl -lcrypto* *Undefined first referenced* * symbol in file* *wattr_on NCursesFrontend.o* *wattr_off NCursesFrontend.o* *ld: fatal: symbol referencing errors. No output written to nzbget* *collect2: ld returned 1 exit status* **** Error code 1* *make: Fatal error: Command failed for target `nzbget'* *Current working directory /temp-nzbget/nzbget-11.0* **** Error code 1* *make: Fatal error: Command failed for target `all'* This is the error i get when compiling par2cmdline *# sudo make* *make all-am* *if g++ -DHAVE_CONFIG_H -I. -I. -I. -Wall -g -O2 -MT reedsolomon.o -MD -MP -MF ".deps/reedsolomon.Tpo" -c -o reedsolomon.o reedsolomon.cpp; \* *then mv -f ".deps/reedsolomon.Tpo" ".deps/reedsolomon.Po"; else rm -f ".deps/reedsolomon.Tpo"; exit 1; fi* *In file included from par2cmdline.h:265:0,* * from reedsolomon.cpp:20:* *par2fileformat.h:67:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PACKET_HEADER::hash' [enabled by default]* *par2fileformat.h:68:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PACKET_HEADER::setid' [enabled by default]* *par2fileformat.h:79:18: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEVERIFICATIONENTRY::hash' [enabled by default]* *par2fileformat.h:84:25: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER FILEVERIFICATIONPACKET::header' [enabled by default]* *par2fileformat.h:86:25: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEVERIFICATIONPACKET::fileid' [enabled by default]* *par2fileformat.h:87:33: warning: ignoring packed attribute because of unpacked non-POD field 'FILEVERIFICATIONENTRY FILEVERIFICATIONPACKET::entries [0]' [enabled by default]* *par2fileformat.h:99:20: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER FILEDESCRIPTIONPACKET::header' [enabled by default]* *par2fileformat.h:101:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEDESCRIPTIONPACKET::fileid' [enabled by default]* *par2fileformat.h:102:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEDESCRIPTIONPACKET::hashfull' [enabled by default]* *par2fileformat.h:103:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEDESCRIPTIONPACKET::hash16k' [enabled by default]* *par2fileformat.h:127:20: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER MAINPACKET::header' [enabled by default]* *par2fileformat.h:131:28: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash MAINPACKET::fileid [0]' [enabled by default] * *par2fileformat.h:141:20: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER CREATORPACKET::header' [enabled by default]* *par2fileformat.h:151:20: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER RECOVERYBLOCKPACKET::header' [enabled by default]* *In file included from par2cmdline.h:284:0,* * from reedsolomon.cpp:20:* *verificationhashtable.h: In member function 'bool VerificationHashEntry::operator<(const VerificationHashEntry&) const':* *verificationhashtable.h:69:52: warning: suggest parentheses around '&&' within '||' [-Wparentheses]* *verificationhashtable.h: In member function 'bool VerificationHashEntry::operator>(const VerificationHashEntry&) const':* *verificationhashtable.h:73:52: warning: suggest parentheses around '&&' within '||' [-Wparentheses]* *verificationhashtable.h: In static member function 'static const VerificationHashEntry* VerificationHashEntry::Search(const VerificationHashEntry*, const MD5Hash&)':* *verificationhashtable.h:186:64: warning: suggest parentheses around '&&' within '||' [-Wparentheses]* *verificationhashtable.h:190:69: warning: suggest parentheses around '&&' within '||' [-Wparentheses]* *verificationhashtable.h: In member function 'const VerificationHashEntry* VerificationHashTable::FindMatch(const VerificationHashEntry*, const Par2RepairerSourceFile*, FileCheckSummer&, bool&) const':* *verificationhashtable.h:405:126: warning: suggest parentheses around '&&' within '||' [-Wparentheses]* *In file included from par2cmdline.h:284:0,* * from reedsolomon.cpp:20:* *verificationhashtable.h:412:128: warning: suggest parentheses around '&&' within '||' [-Wparentheses]* *verificationhashtable.h:429:118: warning: suggest parentheses around '&&' within '||' [-Wparentheses]* *In file included from par2cmdline.h:289:0,* * from reedsolomon.cpp:20:* *par1fileformat.h: At global scope:* *par1fileformat.h:41:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEHEADER::controlhash' [enabled by default]* *par1fileformat.h:42:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEHEADER::sethash' [enabled by default]* *par1fileformat.h:56:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEENTRY::hashfull' [enabled by default]* *par1fileformat.h:57:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEENTRY::hash16k' [enabled by default] * *reedsolomon.cpp:54:6: error: specializing member 'ReedSolomon >::SetInput' requires 'template<>' syntax* **** Error code 1* *make: Fatal error: Command failed for target `reedsolomon.o'* *Current working directory /tempsab/par2cmdline-0.4* **** Error code 1* *make: Fatal error: Command failed for target `all'* Can you help me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cardenas12 at gmail.com Tue Jul 23 01:30:06 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Mon, 22 Jul 2013 18:30:06 -0700 Subject: [OmniOS-discuss] Trying hard to compile par2cmdline and nzbget In-Reply-To: References: Message-ID: nzbget: You are linking against the wrong version of ncurses: los at Ndnd:% nm /lib/libcurses.so.1| grep wattr_on provided by system/library at 0.5.11-0.151006 vs los at Ndnd:% nm /usr/gnu/lib/amd64/libncurses.so.5.9| grep wattr_on [644] | 230520| 94|FUNC |GLOB |0 |14 |wattr_on provided by library/ncurses at 5.9-0.151006 Also, what's the deal with those four '-L/usr/lib' at the beginning of the compile line? Don't forget, you are going to need -L and -R. See man 1 ld. -- Carlos On Monday, July 22, 2013 at 5:58 PM, Sebastien Messier wrote: > So i'm trying to build stuff for my omnios server and i can't compile nothing. > > This is the error i get when compiling nzbget > > > # make > > /usr/bin/make all-am > > > > > > g++ -g -O2 -L/usr/lib -L/usr/lib -L/usr/lib -L/usr/lib -o nzbget ArticleDownloader.o BinRpc.o ColoredFrontend.o Connection.o Decoder.o DiskState.o DownloadInfo.o Frontend.o Log.o LoggableFrontend.o NCursesFrontend.o NNTPConnection.o NZBFile.o NewsServer.o Observer.o Options.o ParChecker.o ParRenamer.o ParCoordinator.o PrePostProcessor.o QueueCoordinator.o QueueEditor.o RemoteClient.o RemoteServer.o Scanner.o Scheduler.o ScriptController.o ServerPool.o svn_version.o TLS.o Thread.o Util.o XmlRpc.o WebDownloader.o WebServer.o UrlCoordinator.o Unpack.o nzbget.o -lz -lpar2 -lcurses -lresolv -lnsl -lsocket -lxml2 -lsigc-2.0 -lssl -lcrypto > > > > > > Undefined first referenced > > > > > > symbol in file > > > > > > wattr_on NCursesFrontend.o > > > > > > wattr_off NCursesFrontend.o > > > > > > ld: fatal: symbol referencing errors. No output written to nzbget > > > > > > collect2: ld returned 1 exit status > > > > > > *** Error code 1 > > > > > > make: Fatal error: Command failed for target `nzbget' > > > > > > Current working directory /temp-nzbget/nzbget-11.0 > > > > > > *** Error code 1 > > > > > > make: Fatal error: Command failed for target `all' > > > > > > > > > This is the error i get when compiling par2cmdline > > > # sudo make > > make all-am > > if g++ -DHAVE_CONFIG_H -I. -I. -I. -Wall -g -O2 -MT reedsolomon.o -MD -MP -MF ".deps/reedsolomon.Tpo" -c -o reedsolomon.o reedsolomon.cpp; \ > > then mv -f ".deps/reedsolomon.Tpo" ".deps/reedsolomon.Po"; else rm -f ".deps/reedsolomon.Tpo"; exit 1; fi > > In file included from par2cmdline.h:265:0, > > from reedsolomon.cpp:20: > > par2fileformat.h:67:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PACKET_HEADER::hash' [enabled by default] > > par2fileformat.h:68:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PACKET_HEADER::setid' [enabled by default] > > par2fileformat.h:79:18: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEVERIFICATIONENTRY::hash' [enabled by default] > > par2fileformat.h:84:25: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER FILEVERIFICATIONPACKET::header' [enabled by default] > > par2fileformat.h:86:25: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEVERIFICATIONPACKET::fileid' [enabled by default] > > par2fileformat.h:87:33: warning: ignoring packed attribute because of unpacked non-POD field 'FILEVERIFICATIONENTRY FILEVERIFICATIONPACKET::entries [0]' [enabled by default] > > par2fileformat.h:99:20: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER FILEDESCRIPTIONPACKET::header' [enabled by default] > > par2fileformat.h:101:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEDESCRIPTIONPACKET::fileid' [enabled by default] > > par2fileformat.h:102:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEDESCRIPTIONPACKET::hashfull' [enabled by default] > > par2fileformat.h:103:20: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash FILEDESCRIPTIONPACKET::hash16k' [enabled by default] > > par2fileformat.h:127:20: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER MAINPACKET::header' [enabled by default] > > par2fileformat.h:131:28: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash MAINPACKET::fileid [0]' [enabled by default] > > par2fileformat.h:141:20: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER CREATORPACKET::header' [enabled by default] > > par2fileformat.h:151:20: warning: ignoring packed attribute because of unpacked non-POD field 'PACKET_HEADER RECOVERYBLOCKPACKET::header' [enabled by default] > > In file included from par2cmdline.h:284:0, > > from reedsolomon.cpp:20: > > verificationhashtable.h: In member function 'bool VerificationHashEntry::operator<(const VerificationHashEntry&) const': > > verificationhashtable.h:69:52: warning: suggest parentheses around '&&' within '||' [-Wparentheses] > > verificationhashtable.h: In member function 'bool VerificationHashEntry::operator>(const VerificationHashEntry&) const': > > verificationhashtable.h:73:52: warning: suggest parentheses around '&&' within '||' [-Wparentheses] > > verificationhashtable.h: In static member function 'static const VerificationHashEntry* VerificationHashEntry::Search(const VerificationHashEntry*, const MD5Hash&)': > > verificationhashtable.h:186:64: warning: suggest parentheses around '&&' within '||' [-Wparentheses] > > verificationhashtable.h:190:69: warning: suggest parentheses around '&&' within '||' [-Wparentheses] > > verificationhashtable.h: In member function 'const VerificationHashEntry* VerificationHashTable::FindMatch(const VerificationHashEntry*, const Par2RepairerSourceFile*, FileCheckSummer&, bool&) const': > > verificationhashtable.h:405:126: warning: suggest parentheses around '&&' within '||' [-Wparentheses] > > In file included from par2cmdline.h:284:0, > > from reedsolomon.cpp:20: > > verificationhashtable.h:412:128: warning: suggest parentheses around '&&' within '||' [-Wparentheses] > > verificationhashtable.h:429:118: warning: suggest parentheses around '&&' within '||' [-Wparentheses] > > In file included from par2cmdline.h:289:0, > > from reedsolomon.cpp:20: > > par1fileformat.h: At global scope: > > par1fileformat.h:41:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEHEADER::controlhash' [enabled by default] > > par1fileformat.h:42:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEHEADER::sethash' [enabled by default] > > par1fileformat.h:56:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEENTRY::hashfull' [enabled by default] > > par1fileformat.h:57:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEENTRY::hash16k' [enabled by default] > > reedsolomon.cpp:54:6: error: specializing member 'ReedSolomon >::SetInput' requires 'template<>' syntax > > *** Error code 1 > > make: Fatal error: Command failed for target `reedsolomon.o' > > Current working directory /tempsab/par2cmdline-0.4 > > *** Error code 1 > > make: Fatal error: Command failed for target `all' > > > > > Can you help me? > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com (mailto:OmniOS-discuss at lists.omniti.com) > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cardenas12 at gmail.com Tue Jul 23 01:39:36 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Mon, 22 Jul 2013 18:39:36 -0700 Subject: [OmniOS-discuss] dns/multicast Message-ID: Has anyone gotten the mdns pkg working with sshd and other services auto registering? This is on top of resolving nodes. I have the service enabled but must manually register services via dns-sd. My /etc/nsswitch.conf has mdns for the appropriate items. I was hoping to: # ping Lrrr.local # ssh carlos at Ndnd.local -- Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From esproul at omniti.com Tue Jul 23 04:09:36 2013 From: esproul at omniti.com (Eric Sproul) Date: Tue, 23 Jul 2013 00:09:36 -0400 Subject: [OmniOS-discuss] Trying hard to compile par2cmdline and nzbget In-Reply-To: References: Message-ID: Sebastien, You likely should also be using gmake, since /usr/bin/make is Sun make. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at fluffy.co.uk Tue Jul 23 07:20:14 2013 From: ben at fluffy.co.uk (Ben Summers) Date: Tue, 23 Jul 2013 08:20:14 +0100 Subject: [OmniOS-discuss] dns/multicast In-Reply-To: References: Message-ID: <54B9A234-A96B-41F9-A95E-8AEAC3849DD7@fluffy.co.uk> On 23 Jul 2013, at 02:39, Carlos Cardenas wrote: > Has anyone gotten the mdns pkg working with sshd and other services auto registering? This is on top of resolving nodes. > > I have the service enabled but must manually register services via dns-sd. My /etc/nsswitch.conf has mdns for the appropriate items. We use mDNS very successfully for development VMs: http://bens.me.uk/2013/multicast-dns-and-development-virtual-machines But why do you need to do service discovery? mDNSResponder will automatically broadcast `hostname`.local, and you just ssh or whatever to that hostname. Ben -- http://bens.me.uk From carlopmart at gmail.com Tue Jul 23 10:29:22 2013 From: carlopmart at gmail.com (C. L. Martinez) Date: Tue, 23 Jul 2013 12:29:22 +0200 Subject: [OmniOS-discuss] Support for HP Proliant ML150 Message-ID: Hi all, Is this server supported by OmniOS?? And smartarray e200i?? Thanks From esproul at omniti.com Tue Jul 23 13:50:22 2013 From: esproul at omniti.com (Eric Sproul) Date: Tue, 23 Jul 2013 09:50:22 -0400 Subject: [OmniOS-discuss] Installing OmniOS on a X4500 via PXE? In-Reply-To: <926810C0-0CBF-4C7B-9E24-A065D9C821B0@ifm.liu.se> References: <926810C0-0CBF-4C7B-9E24-A065D9C821B0@ifm.liu.se> Message-ID: On Mon, Jul 22, 2013 at 4:16 PM, Peter Eriksson wrote: > I've tried following the instructions in the Wiki on network-installing OmniOS on one of our Sun X4500 Thumpers but the kernel just panics and crashed at the boot stage. Has anyone else succeded in doing this before and have some pointers? > > (We PXE-boot from a Solaris 10 box). > > It works PXE-booting SmartOS on the same box - so I think it *should* work... :-) Indeed. Could you share what the panic is (maybe a screenshot, maybe via a serial console if that system can be configured for it) and what release you're installing? Thanks, Eric From cardenas12 at gmail.com Tue Jul 23 14:57:10 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Tue, 23 Jul 2013 07:57:10 -0700 Subject: [OmniOS-discuss] dns/multicast In-Reply-To: <54B9A234-A96B-41F9-A95E-8AEAC3849DD7@fluffy.co.uk> References: <54B9A234-A96B-41F9-A95E-8AEAC3849DD7@fluffy.co.uk> Message-ID: <64F389CDA06A46549C757AD28E38554C@gmail.com> On Tuesday, July 23, 2013 at 12:20 AM, Ben Summers wrote: > We use mDNS very successfully for development VMs: http://bens.me.uk/2013/multicast-dns-and-development-virtual-machines > > But why do you need to do service discovery? mDNSResponder will automatically broadcast `hostname`.local, and you just ssh or whatever to that hostname. Is that for GZ or NGZ? I enabled the service in the GZ and didn't see any services register nor be able to resolve others outside of dns-sd. For example, Ndnd is my toughbook running OmniOS and Lrrr is my MBP. I could not ssh into Lrrr from Ndnd: # ssh carlos at Lrrr.local nor could I ssh into Ndnd from Lrrr: # ssh carlos at Ndnd.local The only way I could see the mdns services was via dns-sd. -- Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at fluffy.co.uk Tue Jul 23 15:01:18 2013 From: ben at fluffy.co.uk (Ben Summers) Date: Tue, 23 Jul 2013 16:01:18 +0100 Subject: [OmniOS-discuss] dns/multicast In-Reply-To: <64F389CDA06A46549C757AD28E38554C@gmail.com> References: <54B9A234-A96B-41F9-A95E-8AEAC3849DD7@fluffy.co.uk> <64F389CDA06A46549C757AD28E38554C@gmail.com> Message-ID: <61C6A57A-067B-4835-9A99-BDD30697020C@fluffy.co.uk> On 23 Jul 2013, at 15:57, Carlos Cardenas wrote: > On Tuesday, July 23, 2013 at 12:20 AM, Ben Summers wrote: >> We use mDNS very successfully for development VMs: http://bens.me.uk/2013/multicast-dns-and-development-virtual-machines >> >> But why do you need to do service discovery? mDNSResponder will automatically broadcast `hostname`.local, and you just ssh or whatever to that hostname. > > Is that for GZ or NGZ? I enabled the service in the GZ and didn't see any services register nor be able to resolve others outside of dns-sd. You should enable the service in all zones, both GZ and NGZ, for which you want to use mDNS. "Use" here means either broadcast or look up names. Try enabling it in the GZ the NGZs. Ben -- http://bens.me.uk From cardenas12 at gmail.com Tue Jul 23 15:04:49 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Tue, 23 Jul 2013 08:04:49 -0700 Subject: [OmniOS-discuss] dns/multicast In-Reply-To: <61C6A57A-067B-4835-9A99-BDD30697020C@fluffy.co.uk> References: <54B9A234-A96B-41F9-A95E-8AEAC3849DD7@fluffy.co.uk> <64F389CDA06A46549C757AD28E38554C@gmail.com> <61C6A57A-067B-4835-9A99-BDD30697020C@fluffy.co.uk> Message-ID: On Tuesday, July 23, 2013 at 8:01 AM, Ben Summers wrote: > Try enabling it in the GZ the NGZs. I'm not running any zones at the moment. I'll see if this is resolved (reboot) when I boot up my toughbook this evening. -- Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at ifm.liu.se Wed Jul 24 08:29:35 2013 From: peter at ifm.liu.se (Peter Eriksson) Date: Wed, 24 Jul 2013 10:29:35 +0200 Subject: [OmniOS-discuss] Installing OmniOS on a X4500 via PXE? In-Reply-To: References: <926810C0-0CBF-4C7B-9E24-A065D9C821B0@ifm.liu.se> Message-ID: Sure. Here's the stack backtrace: > module /kernel/amd64/genunix: text at [0xfffffffffb9556e0, 0xfffffffffbbe071f] data at 0xfffffffffbc964c0 > Unexpected trap > instruction pointer 0xfffffffffb854162 > code segment 0x28 > flags register 0x10006 > return %rsp 0xc0f788 > return %ss 0x8 > Attempting stack backtrace: > Stack traceback: > mach_kdi_init+2 > bind_primary+16c > getoptstr+bf > boot_prop_finish+451 > Unexpected trap > error code 0x0 > instruction pointer 0xfffffffffb8ad4f9 > code segment 0x28 > flags register 0x10086 > return %rsp 0xc0f660 > return %ss 0x8 > Attempting stack backtrace: > Stack traceback: > kobj_open_file+49 > parse_value+84 > boot_prop_finish+ba > _cmntrap_size+10c > bind_primary+16c > getoptstr+bf > boot_prop_finish+451 > Nested trap > Press any key to reboot. The GRUB menu.lst entry that I'm trying to use is: > title OmniOS Install (Serial) > kernel /omnios/platform/i86pc/kernel/amd64/unix -B console=ttya,ttya-mode="9600,8,n,1,-",install_media=http:///omnios/kayak_bloody.zfs.bz2,install_config=http:///omnios/config,-v > module /omnios/miniroot I followed the instructions on http://omnios.omniti.com/wiki.php?PXEfromNonOmniOS and generated the stuff on a Sun Java Workstation running "OmniOS 5.11 omnios-df542ea 2013.02.08". - Peter On Jul 23, 2013, at 3:50 PM, Eric Sproul wrote: > On Mon, Jul 22, 2013 at 4:16 PM, Peter Eriksson wrote: >> I've tried following the instructions in the Wiki on network-installing OmniOS on one of our Sun X4500 Thumpers but the kernel just panics and crashed at the boot stage. Has anyone else succeded in doing this before and have some pointers? >> >> (We PXE-boot from a Solaris 10 box). >> >> It works PXE-booting SmartOS on the same box - so I think it *should* work... :-) > > Indeed. Could you share what the panic is (maybe a screenshot, maybe > via a serial console if that system can be configured for it) and what > release you're installing? > > Thanks, > Eric From cardenas12 at gmail.com Sun Jul 28 19:31:54 2013 From: cardenas12 at gmail.com (Carlos Cardenas) Date: Sun, 28 Jul 2013 12:31:54 -0700 Subject: [OmniOS-discuss] Switching syslog with rsyslog In-Reply-To: <982CC057AC1542D2B195B5658FB32D47@gmail.com> References: <12FA49CA183D4402B05F59DC62C29A53@gmail.com> <20130716030524.GU98158@eschaton.local> <51e4bf86.8358440a.1473.385f@mx.google.com> <250C5563A9C74B918C8B152090616C2A@gmail.com> <982CC057AC1542D2B195B5658FB32D47@gmail.com> Message-ID: <762596BC2411406D908FEE8E1C83A920@gmail.com> I've resolved these compile time issues. All pkgs are 32 and 64 bit in one wad. https://github.com/omniti-labs/omnios-build/pull/28 -- Carlos On Saturday, July 20, 2013 at 5:07 PM, Carlos Cardenas wrote: > Ok? > > I have rsyslog 7.4.3 building/running with Guardtime enabled. As a result of jumping from 7.3.9 to 7.4.3, I had to add several new pkgs (deps): > * libguardtime (Guardtime C SDK) > * guardtime (Guardtime Client utility) > * python26-docutils (build dep, generate man pages) > > I've also added rsyslog diag and user tools to allow for the additional functionality of using Guardtime within rsyslog. > > The one caveat I have with the latest rsyslog with GT support is that there is bug with the 64bit version of libguardtime linking with curl so rsyslog is 32bit. I'm opening a bug report with GT on this and hope to have this resolved soon. > > That said, is 32bit fine or do y'all want to wait until we have 64bit as well? > > How do y'all want the PRs done: all in one or one PR per pkg? > > Thanks in advance. > > -- > Carlos > > > On Tuesday, July 16, 2013 at 11:12 AM, Carlos Cardenas wrote: > > > I'll send an PR later this week{end}. > > > > -- > > Carlos > > > > > > On Tuesday, July 16, 2013 at 6:35 AM, Eric Sproul wrote: > > > > > > > > > > > > > > On Mon, Jul 15, 2013 at 11:35 PM, wrote: > > > > That's awesome Chris, where can I find the package source so I can update to the latest stable version? GitHub or somewhere else? > > > > > > The build scripts for ms.omniti.com (http://ms.omniti.com) packages are in the omniti-ms branch of omnios-build: https://github.com/omniti-labs/omnios-build/tree/omniti-ms > > > _______________________________________________ > > > OmniOS-discuss mailing list > > > OmniOS-discuss at lists.omniti.com (mailto:OmniOS-discuss at lists.omniti.com) > > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivelin.slavov at gmail.com Thu Jul 25 10:55:48 2013 From: ivelin.slavov at gmail.com (Ivelin Slavov) Date: Thu, 25 Jul 2013 13:55:48 +0300 Subject: [OmniOS-discuss] Iscsi initiator problems Message-ID: Hi everyone, I have some trouble with the OmniOS iscsi initiator on a host. Host is using SunOS 5.11 omnios-d3950d8 i86pc i386 i86pc Solaris. I initiate a session to a TGP ( linux ) served target and when issuing the command ( using iscsiadm add static-config ) and when I e iscsiadm list target -S" it outputs Target: iqn.2008-03.com.storage:0014abcd-5f56-4ba8-9e3b-7efbd87d19be > Alias: - > TPGT: 1 > ISID: 4000002a0000 > Connections: 1 > > as opposed to the proper output Target: iqn.2008-03.com.storage:0014abcd-5f56-4ba8-9e3b-7efbd87d19be > Alias: - > TPGT: 1 > ISID: 4000002a0000 > Connections: 1 > LUN: 1 > Vendor: IET > Product: VIRTUAL-DISK > OS Device Name: /dev/rdsk/c31t161d0s2 This worked fine for some time, but then The session seems to be initiated properly, but the logical units are not. In the kernel log I see: Jul 25 07:46:35 storage0 iscsi: [ID 248668 kern.warning] WARNING: iscsi > driver unable to online iqn.2008-03.com.mystorage:node23 lun 0 > Jul 25 07:46:35 storage0 iscsi: [ID 248668 kern.warning] WARNING: iscsi > driver unable to online iqn.2008-03.com.mystorage:node23 lun 1 Reloading the iscsi module fixed the issue svcadm disable svc:/network/iscsi/initiator:default > modunload -i 189 > svcadm enable svc:/network/iscsi/initiator:default But I am concerned about what caused it, since I have some automated procedures to online/offline remote targets, and it will be very nasty if it stopped working in the middle of the night. I think there might be a BUG somewhere in the kernel module. I can provide additional details, if someone is wiling to look into problem, since I am not (at all) fond of kernel developing. Regards, Ivelin Slavov -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperkin at joyent.com Tue Jul 30 14:11:38 2013 From: jperkin at joyent.com (Jonathan Perkin) Date: Tue, 30 Jul 2013 15:11:38 +0100 Subject: [OmniOS-discuss] pkgsrc-2013Q2 binary packages for illumos now available Message-ID: <20130730141138.GF631@joyent.com> I'm pleased to announce that the pkgsrc-2013Q2 release for illumos platforms is now available. This is an alternative repository of over 10,000 binary packages built for illumos systems. A quick-start tutorial is available here: http://www.perkin.org.uk/pages/pkgsrc-binary-packages-for-illumos.html and an overview of the changes for pkgsrc-2013Q2 is available here: http://www.perkin.org.uk/posts/whats-new-in-pkgsrc-2013Q2.html One of the major improvements with the 2013Q2 release is a working Xorg for illumos, and this has allowed us to demonstrate some of the available desktop environments, using OmniOS as the base platform: GNOME 2.32 with Evolution and Firefox 22: http://www.perkin.org.uk/files/images/2013Q2-gnome.png KDE 4.10.3: http://www.perkin.org.uk/files/images/2013Q2-kde4.png XFCE 4.6 with Gnumeric and Abiword: http://www.perkin.org.uk/files/images/2013Q2-xfce4.png Enlightenment 0.17 with GIMP: http://www.perkin.org.uk/files/images/2013Q2-e17.png Awesome: http://www.perkin.org.uk/files/images/2013Q2-awesome.png This of course is just a selection, there are many more environments and applications available, as well as all the usual development tools and miscellaneous Unix utilities. Please let us know if software you need is missing, and feel free to raise bug reports for things which aren't working as expected. You can find URLs for these in the installation tutorial above. Thanks, -- Jonathan Perkin - Joyent, Inc. - www.joyent.com From esproul at omniti.com Tue Jul 30 18:04:02 2013 From: esproul at omniti.com (Eric Sproul) Date: Tue, 30 Jul 2013 14:04:02 -0400 Subject: [OmniOS-discuss] pkg.omniti.com/omnios planned maintenance Message-ID: FYI, There will be an approximately 30-minute outage for http://pkg.omniti.com/omnios/ on Thursday, August 1 at 13:30 UTC. This is for planned maintenance on the system that hosts the OmniOS pkg repos, and affects availability for both release and bloody repos. We apologize for the inconvenience. Eric