Re: [OpenIndiana-discuss] Edit file in /etc/ from InstallCD
jason matthews writes: > On Aug 14, 2013, at 12:38 PM, Harry Putnam wrote: > > >> Jim K responded: >>> No, this is an "alternate root" - a path prepended to all automatically >>> mounted datasets from rpool, so that they do not conflict with paths >>> that already exist on your system (from LiveCD). Disk names should not >>> be needed as ZFS should find the pools (at least, on those HBAs/disk >>> controllers for which the Live media has drivers). >> >> OK, but I'm a bit lost. Maybe to unskilled to understand. Lets start >> what do you mean by 'ZFS should find the pools' >> >> The live media must have drivers for all my disks since I've installed >> them from the live media. >> >> Are you saying that `zpool list' should 'see' them? >> > > Not initially. But, zpool import, should see them. Once imported, > zpool list will see them. > > Import the pool by following Kilmov's instructions. OK, but unless JimK meant something else was to be inserted in the command, it fails here: jack@openindiana:~$ zpool import -N -R /realroot rpool cannot import 'rpool': no such pool available I'm sure I must be really testing everyone's patience but I must just be a bit too dense to understand what I'm being told to do. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Edit file in /etc/ from InstallCD
On Aug 14, 2013, at 12:38 PM, Harry Putnam wrote: > Jim K responded: >> No, this is an "alternate root" - a path prepended to all automatically >> mounted datasets from rpool, so that they do not conflict with paths >> that already exist on your system (from LiveCD). Disk names should not >> be needed as ZFS should find the pools (at least, on those HBAs/disk >> controllers for which the Live media has drivers). > > OK, but I'm a bit lost. Maybe to unskilled to understand. Lets start > what do you mean by 'ZFS should find the pools' > > The live media must have drivers for all my disks since I've installed > them from the live media. > > Are you saying that `zpool list' should 'see' them? > Not initially. But, zpool import, should see them. Once imported, zpool list will see them. Import the pool by following Kilmov's instructions. j. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oi_151a8 is out
Dave Koelmeyer writes: > http://wiki.openindiana.org/oi/oi_151a_prestable8+Release+Notes A quick search with slider or auto seems to indicate there were no changes to the time-slider. Is that a correct assumption? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] VMware (OpenIndiana-discuss Digest, Vol 37, Issue 15)
>> the same servers as iSCSI targets has no iSCSI errors at the same time as >> VMware is freaking out > > Is VMware using iSCSI as well or NFS? Tried it with both (iSCSI originally), and oddly it's basically the exact same issue (frequent disconnects) between NFS and iSCSI. You would be convinced it's network related, but nothing shows up obviously wrong in the switch logs and obviously the OpenIndiana iSCSI initiators (two of which are guest OSs on the VMware cluster!) aren't affected at all. You get a bizarre situation where VMware is complaining about iSCSI going up and down, yet the VMs themselves don't register any problems whatsoever. Thanks, James. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Edit file in /etc/ from InstallCD
Jim Klimov writes: >> Harry wrote: Anyway, what do I have to do to get to those files in /etc now that the OS will not boot? [...] Lucas wrote: >>> Can you >>> zpool import -R /realroot rpool >>> to import the rpool under /realroot ? You might also have to mount >>> the filesystems after that , or create the directory before hand. [...] Harry replied: >> Before I do irreparable damage: >> Is "realroot" supposed to be a disc name like: c4d0 with the solaris >> partition s0, like c4d0s0? Jim K responded: > No, this is an "alternate root" - a path prepended to all automatically > mounted datasets from rpool, so that they do not conflict with paths > that already exist on your system (from LiveCD). Disk names should not > be needed as ZFS should find the pools (at least, on those HBAs/disk > controllers for which the Live media has drivers). OK, but I'm a bit lost. Maybe to unskilled to understand. Lets start what do you mean by 'ZFS should find the pools' The live media must have drivers for all my disks since I've installed them from the live media. Are you saying that `zpool list' should 'see' them? When booted from the install media iso: zpool list shows .. well not much: jack@openindiana: ~$ sudo zpool list no pools available > When the pool is imported, you can try "zfs mount -a" to mount all of > the datasets marked for auto-mounting. It is possible, however, that > your rootfs dataset would not mount because the mount-point for it is > not empty. Won't I need to mount a disc that has the installed os on it first? [...] snipped the handy detailed commands ... thanks I must need a more basic step in here somewhere. Looking from the install media with 'format', my discs are 'seen': $ sudo format AVAILABLE DISK SELECTIONS: 0. c4d0 /pci@0,0/pci-ide@1,1/ide@0/cmdk@0,0 1. c4d1 /pci@0,0/pci-ide@1,1/ide@0/cmdk@1,0 2. c6t0d0 /pci@0,0/pci8086,2829@d/disk@0,0 3. c6t1d0 /pci@0,0/pci8086,2829@d/disk@1,0 4. c6t2d0 /pci@0,0/pci8086,2829@d/disk@2,0 5. c6t3d0 /pci@0,0/pci8086,2829@d/disk@3,0 The os disks, (setup as a mirrored rpool): 0. c4d0 1. c4d1 Not sure what is unknown about them... they are IDE discs. and I've been running 151a7 on it for over a week now. 2 and 3 are zpool hp1 4 and 5 are zpool hp2 Bother are mirrored 2 disc zpools But I'm still not 'getting' how to make any of this available to 'jack' on the install media? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] VMware (OpenIndiana-discuss Digest, Vol 37, Issue 15)
On Aug 14, 2013, at 11:38 AM, James Relph wrote: > the same servers as iSCSI targets has no iSCSI errors at the same time as > VMware is freaking out Is VMware using iSCSI as well or NFS? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Upgrade to oi_151a8 fails on one machine
On Wed, Aug 14, 2013 at 11:57:42AM +0100, Jon Tibble wrote: > For debugging updates use the process here: > > http://wiki.openindiana.org/oi/Troubleshooting+image-update+failures I tried it first with only the `entire' package, like this: # pkg install --no-refresh -nv pkg:/entire@0.5.11,5.11-0.151.1.8 > /tmp/pkg-debug.log 2>&1 This is the beginning of the output: pkg install: No solution was found to satisfy constraints maintained incorporations: None Plan Creation: dependency error(s) in proposed packages: No suitable version of required package pkg://openindiana.org/system/locale/support/turkish@0.1,5.11-0.151.1:20110912T032358Z found: Reject: pkg://openindiana.org/system/locale/support/turkish@0.1,5.11-0.151.1:20110912T032358Z Reason: All acceptable versions of 'require' dependency on pkg:/gnome/documentation/locale/extra are obsolete There were 1199 instances of `No suitable version' in the output. The curious thing was that the rejected package was not installed on the local system, although it was available from openindiana.org . Others mentioned that I checked were also not installed. When I tried the same `pkg install' command on another machine that was still at oi_151a7, the output seemed fine. There were no rejected files. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] VMware (OpenIndiana-discuss Digest, Vol 37, Issue 15)
I've looked at subsystem performance and had things like zpool iostat running when the issue was occurring, and there's just nothing stressing the systems enough. Plus the OpenIndiana servers using the same servers as iSCSI targets has no iSCSI errors at the same time as VMware is freaking out. I would have expected the Oi initiators to at least log a few re-writes or iSCSI errors if it was a general "the iSCSI target is misbehaving" problem. Thanks, James Principal Consultant Website:www.themacplace.co.uk On 14 Aug 2013, at 08:33, Ong Yu-Phing wrote: > so far we've been discussing network. How about the disk subsystem side? > I've had a situation where a rebuild (RAID10 equivalent with 3x RAID1 vdevs, > had to replace a faulty disk), together with an overnight snapshot and > replication to another server, was "enough" to cause iscsi timeouts. > > On 13/08/2013 21:18, Doug Hughes wrote: >> We have lacp working between force10, hp, and cisco switches in all possible >> combinations with no difficulties. We do monitor and alert on excessive >> errors and drops for interfaces, but lacp isnt a culprit. If anything, it's >> an underlying interface when we find them. Also, it beats the heck out of >> spanning tree and is 2 orders of magnitude simpler than ospf, and 1 order >> simpler and more portable than ecmp. I am quite surprised by your >> observations. >> >> Sent from my android device. >> >> -Original Message- >> From: "Edward Ned Harvey (openindiana)" >> To: Discussion list for OpenIndiana >> Sent: Tue, 13 Aug 2013 7:22 AM >> Subject: Re: [OpenIndiana-discuss] VMware >> >>> From: James Relph [mailto:ja...@themacplace.co.uk] >>> Sent: Monday, August 12, 2013 4:47 PM >>> >>> No, we're not getting any ping loss, that's the thing. The network looks >>> entirely faultless. We've run pings for 24 hours with no ping loss. >> Yeah, I swore you said you had ping loss before - but if not - I don't think >> ping alone is sufficient. You have to find the error counters on the LACP >> interfaces. Everybody everywhere seems to blindly assume LACP works >> reliably, but to me, simply saying the term "LACP" is a red flag. It's >> extremely temperamental, and the resultant behavior is exactly as you've >> described. >> >> ___ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss >> >> > > Disclaimer: use of our emails are governed by terms at > http://360-jambo.com/emd > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Checksum errors on high-volume / high-speed writes
Good morning, Last week we put three identical oi_151a7 systems into pre-production. Each system has 240 drives in 9drive RAIDZ1 vdevs (I'm aware of the potential DR issues with this configuration and I'm ok with them in this case). The drives are Seagate Enterprise nearline SAS, 7200RPM. The servers are all identical Supermicro servers with dual 4C Xeons, maxed out memory and LSI 9200-8E HBA's. Intel MLC ssd for boot and cache, Intel SLC for ZIL. All of these are components we have used many times before without issue. While loading up the systems with data we started to see low numbers of checksum errors across all drives. The first time we saw it we pulled the drives and low level tested them, no errors. Scrub finds no issues. iostat -EXN shows no hard, soft or transport errors. iostat -xnz shows no anomalous drives. During the load test we're pushing between 14 and 16Gb/sec to each system and the CPU load average does go up significantly (about 8) but that is to be expected with a RAIDZ1 volume this big and this busy. I don't want to put the systems into prodcution until I figure out if I have a problem or not. Thoughts / ideas? thank you, Willem ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Upgrade to oi_151a8 fails on one machine
On Wed, Aug 14, 2013 at 01:35:04PM +0100, Richard Jones wrote: > On Wed, Aug 14, 2013 at 11:57:42AM +0100, Jon Tibble wrote: > > For debugging updates use the process here: > > > > http://wiki.openindiana.org/oi/Troubleshooting+image-update+failures > > Hi John, all, > > I'm having trouble with the update, though I suspect it's a local issue: [...] Relocated /var onto the rpool seems to fix things. -- Richard Jones +44 7843 588 599 "Quod gratis asseritur, gratis negatur" Privacy notice: http://www.jonze.com/privacy.html ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] oi-dev-151a8-text-x86.usb fails, root full
oi-dev-151a8-text-x86.usb fails with unable to alloc / root full message and then a stream of SMF errors infinitely looping. a7-text and oi-dev-151a8-live-x86.usb work fine. John groenv...@acm.org ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Nvidia rotation in oi_151a8
FWIW The nvidia-settings program following an upgrade from oi_151a5 to oi_151a8 no longer provides an option to rotate the screen to portrait mode. I've looked to see if it moved, but can't find anything. The xorg.conf files are the same for both BEs. "xrandr -o left" works though. ==> oi_151a5 <== Nvidia driver 280.13 NV-control 1.27 ==> oi_151a8 <== Nvidia server 304.88 NV-control 1.28 Does anyone know anything about the change? Obviously not a big deal as an alternative method is available. Thanks, Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Upgrade to oi_151a8 fails on one machine
On 13/08/2013 6:36 PM, Gary Mills wrote: The second gave me trouble. I used the same command, but it only updated 37 packages. When I rebooted into the new BE, the kernel version was still oi_151a7 . What happens if you pkg-update this new image? I remember some oi updates that needed to be run twice. I rebooted back to the old BE and destroyed the new one. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Upgrade to oi_151a8 fails on one machine
On Wed, Aug 14, 2013 at 11:57:42AM +0100, Jon Tibble wrote: > For debugging updates use the process here: > > http://wiki.openindiana.org/oi/Troubleshooting+image-update+failures Hi John, all, I'm having trouble with the update, though I suspect it's a local issue: pkg: An unexpected error happened during update: Traceback (most recent call last): File "/usr/bin/pkg", line 5954, in handle_errors __ret = func(*args, **kwargs) File "/usr/bin/pkg", line 5937, in main_func pargs=pargs, **opts) File "/usr/bin/pkg", line 2323, in update reject_list=reject_pats, update_index=update_index) File "/usr/bin/pkg", line 1583, in __api_op ret_code = __api_execute_plan(_op, _api_inst) File "/usr/bin/pkg", line 1269, in __api_execute_plan api_inst.execute_plan() File "/usr/lib/python2.6/vendor-packages/pkg/client/api.py", line 2130, in execute_plan self.__be_name) File "/usr/lib/python2.6/vendor-packages/pkg/client/bootenv.py", line 428, in init_image_recovery img.find_root(self.clone_dir, exact_match=True) File "/usr/lib/python2.6/vendor-packages/pkg/client/image.py", line 522, in find_root exact_match, startd, d) ImageNotFoundException I don't know if this helps: # beadm list BE Active Mountpoint Space Policy Created openindiana NR / 1.84G static 2013-04-08 06:49 # zfs list NAMEUSED AVAIL REFER MOUNTPOINT hotspur8.18T 4.60T 8.01T /hotspur hotspur/swap 8.25G 4.60T 115K - hotspur/var 783M 4.60T 783M legacy rpool 2.48G 4.84G 44.5K /rpool rpool/ROOT 1.77G 4.84G31K legacy rpool/ROOT/openindiana 1.77G 4.84G 1.69G / rpool/dump 729M 4.84G 729M - rpool/export 99K 4.84G32K /export rpool/export/home67K 4.84G32K /export/home rpool/export/home/richard35K 4.84G35K /export/home/richard Note that I moved /var onto pool made of real disks as rpool is on a USB stick. If that makes any difference. Thanks, Richard -- Richard Jones +44 7843 588 599 "Quod gratis asseritur, gratis negatur" Privacy notice: http://www.jonze.com/privacy.html ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Upgrade to oi_151a8 fails on one machine
For debugging updates use the process here: http://wiki.openindiana.org/oi/Troubleshooting+image-update+failures - Original Message - From: Carl Brewer To: openindiana-discuss@openindiana.org Cc: Sent: Wednesday, 14 August 2013, 1:01 Subject: Re: [OpenIndiana-discuss] Upgrade to oi_151a8 fails on one machine On 14/08/2013 8:36 AM, Gary Mills wrote: > The first machine upgraded from oi_151a7 to oi_151a8 with no problems. > The command I used was: pkg image-update --be-name oi_151a8 . It > updated 879 packages into a new BE. It looked good when I rebooted > into that BE. > > The second gave me trouble. I used the same command, but it only > updated 37 packages. When I rebooted into the new BE, the kernel > version was still oi_151a7 . I rebooted back to the old BE and > destroyed the new one. > > In October, I had upgraded this second machine from oi_151a5 to > oi_151a7, with no problems. It updated 947 packages that time. > > I did notice that the package `entire' was missing on the second > machine, although it was present on the first one. I had been > upgrading this second machine periodically, starting with > opensolaris-126 . I suppose I must have removed `entire' somewhere > along the way. Perhaps that was the cause of the problem, but why > did the upgrade to oi_151a7 succeed? > > I tried adding the correct version of `entire' for oi_151a7, in a new > BE, but `pkg image-update -n' still told me it would update only 37 > packages. > > What could be preventing this upgrade from working? What should I do > next? I don't know, but I have seen the same problem. I have two OI boxes, one is old (dates back to OS 90 or something ... 5 years or so and has been updated many, many times through pkg image-updates) and the other was built with OI 151a7 a few months ago. The "old" one displayed the same problem you describe, the "new" one was fine. I had made the new one a hipster version in the mean time though, and then pulled it back to 151a8 dev release three days ago. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] oi_151a8 is out
On 08/13/13 08:58 PM, Milan Jurik wrote: >> First impression after updating from a7 are >> Desktop icons somehow got sorted in the left , no GNOME Trash applet >> working, (adding it works but is not visible/working in a8 , it is seen >> as multiple Trash applets later in Hipster) > Bug number? I found easy to locate OI-related bugs on the link I bookmarked: https://www.illumos.org/projects/openindiana/issues I reported these bugs: OI Bug #4042 : "151a8/dev sort desktop icons on the left of the screen" (https://www.illumos.org/issues/4042) OI Bug #4043 : "151a8/dev Trash GNOME applet not visible/not working" (https://www.illumos.org/issues/4043 >> Pidgin (internet messenger) is crashing in 151a8 /dev, with dumping >> core: > Bug number? I created bug report #4041 "151a8 Pidgin dumps core" (https://www.illumos.org/issues/4041) ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] VMware (OpenIndiana-discuss Digest, Vol 37, Issue 15)
so far we've been discussing network. How about the disk subsystem side? I've had a situation where a rebuild (RAID10 equivalent with 3x RAID1 vdevs, had to replace a faulty disk), together with an overnight snapshot and replication to another server, was "enough" to cause iscsi timeouts. On 13/08/2013 21:18, Doug Hughes wrote: We have lacp working between force10, hp, and cisco switches in all possible combinations with no difficulties. We do monitor and alert on excessive errors and drops for interfaces, but lacp isnt a culprit. If anything, it's an underlying interface when we find them. Also, it beats the heck out of spanning tree and is 2 orders of magnitude simpler than ospf, and 1 order simpler and more portable than ecmp. I am quite surprised by your observations. Sent from my android device. -Original Message- From: "Edward Ned Harvey (openindiana)" To: Discussion list for OpenIndiana Sent: Tue, 13 Aug 2013 7:22 AM Subject: Re: [OpenIndiana-discuss] VMware From: James Relph [mailto:ja...@themacplace.co.uk] Sent: Monday, August 12, 2013 4:47 PM No, we're not getting any ping loss, that's the thing. The network looks entirely faultless. We've run pings for 24 hours with no ping loss. Yeah, I swore you said you had ping loss before - but if not - I don't think ping alone is sufficient. You have to find the error counters on the LACP interfaces. Everybody everywhere seems to blindly assume LACP works reliably, but to me, simply saying the term "LACP" is a red flag. It's extremely temperamental, and the resultant behavior is exactly as you've described. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss Disclaimer: use of our emails are governed by terms at http://360-jambo.com/emd ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
