[OmniOS-discuss] FLAG DAY --> do not build omnios-build on bloody until the binaries are updated
I've pushed back the changes for gcc51 into omnios-build. I now need to build it a final time, and test upgrading. If you pull changes into omnios-build, you will be able to build most of the world, but not the gcc51 portions of it. Watch this list for a followup announcement when the bloody binaries on IPS are updated. Thank you for your patience, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Adding a disk array after boot
15 июня 2015 г. 9:27:40 CEST, Dale Ghent пишет: > >> On Jun 13, 2015, at 10:36 AM, Graham Stephens > wrote: >> >> On 13/06/2015 15:01, Stephan Budach wrote: >>> Am 13.06.15 um 14:54 schrieb Graham Stephens: Perhaps another dumb question, but here goes... I currently have a FC disk array attached to a server acting, among other things, as a Samba file server. I don't need the files >serving all the time, so mainly start the machine (it is normally off overnight due to the noise) without the disk array turned on unless >I know I will need the files in advance. ZFS doesn't seem to mind as long as the disks are attached/not attached at boot, and I don't >try turning the array on while the server is running. I am moving several boxes into one quieter zoned box that I would >like to have on 24/7, and the Samba server is intended to go into one of those zones. I will eventually swap the external array over to internal disks, but it isn't going to happen straight away; so what >I would like to ask is: Is there a way for me to be able to turn the disk array on and off >as necessary (it will become the noisy part of the setup), without me having to reboot the main box (with all the zones, etc) every time? >>> >>> Each FC equipment I know of will issue a FC reset upon booting and >>> OmniOS will pick that up. However, there is of course also a means >of >>> having the OmniOS box perform a FC reset on the bus which would also >>> spurr a disk discovery, after which ZFS will happily import your >>> formerly exportet(!) zpool without fuss. >>> >>> Cheers >>> >> >> Ah! I hadn't thought to export the zpools first. If that's all I need >to do then I'll be a very happy chap! > >Yes, do make sure that the zpools are first exported (which implies an >unmount of its constituent filesystems) so that the disks are properly >quiesced. > >In FC-land and on the device level, there are a few old commands you >can issue to get the view of things once you unplug your array, or plug >it back in: > ># view configured FC drives and controllers >cfgadm -al > ># force a re-probe of a specific (FC) controller on the driver level >cfgadm -c configure > ># clean up no-longer present disk device links under /dev and /devices >devfsadm -Cv disks > ># forcibly re-create them if for some reason they aren’t around >devfsadm -v disks > ># if (a) drive(s) fails to show up on a known controller, send the >whole thing a LIP (Loop Init Protocol) command >fcinfo force-lip(the old old OLD solaris >command to do this was/is luxadm -e forecelip) > >/dale > > > > >___ >OmniOS-discuss mailing list >OmniOS-discuss@lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss You might also want to SMFize your pool instances and stuff that depends on the pool (zones, samba, etc.) along the lines of https://github.com/jimklimov/illumos-smf-zfspools and https://github.com/jimklimov/illumos-smf-zones - so you can just 'svcadm disable -ts myfcarray' and when that's done - unplug it. Grab an ePDU and power it off/onn programmatically for bonus nerd points ;) HTH, Jim Klimov -- Typos courtesy of K-9 Mail on my Samsung Android ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Problem updating ms-omniti local repo
T hank you for the answer Volker , I've recreated the repo following your indications and I still have the same problem when I try to update the repo. thank you for your time regards - Original Message - From: "Javier Lopez" To: omnios-discuss@lists.omniti.com Cc: "Trixter IT Dept" Sent: Monday, June 15, 2015 2:22:49 PM Subject: Problem updating ms-omniti local repo Hello, I've created a local mirror of the ms.omniti.com repository with the following command: #> pkgrepo create /path/ms.omniti.com/ #> pkgrecv -s http://pkg.omniti.com/omniti-ms/ -d /path/ms.omniti.com/ '*' Everything were fine but when I tried to update the repo I get this error message #> pkgrecv -s http://pkg.omniti.com/omniti-ms/ -d /path/ms.omniti.com/ '*' Processing packages for publisher omniti-ms ... Retrieving catalog ' http://pkg.omniti.com/omniti-ms/ '... Unable to retrieve package data for publisher 'omniti-ms' from one of the following origin(s): http://pkg.omniti.com/omniti-ms/ The catalog retrieved from one of the origin(s) listed above only contains package data for: ms.omniti.com. This is either a result of invalid origin information being provided for publisher 'omniti-ms', or because the wrong publisher name was provided when this publisher was added. Retrieving and evaluating 809 package(s)... PROCESS ITEMS GET (MB) SEND (MB) omniti/runtime/nodejs 1/809 6.6/1805.6 0.2/5478.3 pkgrecv: 'open' failed for transaction ID '1430420933_pkg%3A%2F%2Fms.omniti.com%2Fomniti%2Fruntime%2Fnodejs%400.10.21%2C5.11-0.151014%3A20150430T190853Z': The specified FMRI, 'pkg://ms.omniti.com/omniti/runtime/nodejs@0.10.21,5.11-0.151014:20150430T190853Z', already exists or has been restricted. pkgrecv: Cached files were preserved in the following directory: /var/tmp/pkgrecv-hLEfRQ Use pkgrecv -c to resume the interrupted download. I'm stucked here. Any help or pointers will be apreciated. Regards. Javier. ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Hello bloody folks! Check out preliminary gcc5.1 support
On Tue, Jun 16, 2015 at 9:14 AM, Dan McDonald wrote: >> Ah, I just looked at the make_package() function. Out of (perhaps >> morbid) curiosity, what are the obstacles? > > -bash-4.3$ pkg list nfs > NAME (PUBLISHER) VERSION > IFO > service/file-system/nfs 0.5.11-0.151015 > i-- > system/file-system/nfs0.5.11-0.151015 > i-- > -bash-4.3$ > > Though those are in ON, to be fair. Yeah, illumos-gate packages are kind of their own thing-- if manifests there are wonky, they should be fixed upstream. pkglint might be of help there, nonetheless. IM(V)HO we should be pkglinting all the omnios-build bits though. In saying that, I realize I should be doing the same for the repo *I* manage. ;) /me goes to made a todo item... >> This is mostly harmless, but as in your case here, it's creating >> unnecessary work for you to change to gcc5. > > Since I've *done* the work already, however, are you okay with the existing > changes. I've been running a gcc5'ed bloody on&off for the past 1-2 weeks. I > also have a gcc5 install ISO which I need to confirm, but I think I'm good. > If you're good, I'll mark you as a reviewer, integrate, rebuild the world, > and see if a conventional "pkg update" works on my pristine bloody system. Yeah, let's possibly take it as a followup item to fix unnecessary dependencies. +1 from me. Eric ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Hello bloody folks! Check out preliminary gcc5.1 support
> On Jun 10, 2015, at 10:00 AM, Eric Sproul wrote:
>
> On Wed, Jun 10, 2015 at 8:46 AM, Dan McDonald wrote:
>>
>>> On Jun 8, 2015, at 10:46 AM, Eric Sproul wrote:
>>>
>>> On Fri, Jun 5, 2015 at 3:46 PM, Dan McDonald wrote:
Any code-minded people in the community should have a look at the above
webrev, and tell me what you think. Unlike the last compiler change done
for r151008, this is a jump from 4 to 5, so "g{cc,++}-N-runtime" has a new
value of N, namely 5. The prior versions of gcc runtime are in place
(.so.6.0.XX), but the package name has been changed. I've use the
"renamed" attribute for gcc/++-4-runtime to aid in this regard.
>>>
>>> Dan,
>>> Great work so far. Mostly looks good to me, though I'm curious if
>>> pkglint is/will be complaining about redundant require dependencies.
>>
>> Remember -- we don't run pkglint by default. (Some existing package naming
>> schemes make that difficult/impossible.)
>
> Ah, I just looked at the make_package() function. Out of (perhaps
> morbid) curiosity, what are the obstacles?
-bash-4.3$ pkg list nfs
NAME (PUBLISHER) VERSIONIFO
service/file-system/nfs 0.5.11-0.151015i--
system/file-system/nfs0.5.11-0.151015i--
-bash-4.3$
Though those are in ON, to be fair.
>> The whole DEPENDS_IPS/BUILD_DEPENDS_IPS/PKG_DEPENDS_IPS is screwy to me. A
>> bit of history, and a suggested what's-right course of action may be in
>> order.
>
> OK, so to go _really_ far back into the Dark Ages, our build system
> was originally created to make SVR4 packages for Solaris 10 in
> OmniTI's hosting environments. No fancy auto-dependency tools there,
> so the build had to declare all runtime dependencies manually. That
> persisted through the transition to SXCE, which was still SVR4.
> Fast-forward to IPS and OmniOS, which grew organically from the SVR4
> builds, and the habit of specifying all deps manually was already
> deeply ingrained.
Inherited S10/SVR4 stuff -- got it!
> So now, in the all-IPS world, with pkgdepend, we generally don't need
> to specify run-time dependencies. pkgdepend can handle ELF, Java, and
> some scripts (Python, Perl, shell), and maybe a few other minor
> things. It can't do Perl modules, that's one glaring issue that comes
> to mind, so there are still cases where you need to specify *some*
> runtime deps. BUT, since we don't run pkglint, we haven't been good
> about cleaning up the unnecessary DEPENDS_IPS items, and our packages
> will end up with either duplicate deps or unnecessary ones, e.g.
>
> $ pkg contents -t depend -o type,fmri bash
> TYPEFMRI
> require pkg:/SUNWcs@0.5.11-0.151014
> require pkg:/system/library@0.5.11-0.151014
> require system/library/gcc-4-runtime
>
> The first two came from pkgdepend, but bash doesn't actually need
> gcc-4-runtime (verified with ldd). It may have at one time, or
> someone was just over-zealous in applying an assumed dependency
> without validation.
>
> This is mostly harmless, but as in your case here, it's creating
> unnecessary work for you to change to gcc5.
Since I've *done* the work already, however, are you okay with the existing
changes. I've been running a gcc5'ed bloody on&off for the past 1-2 weeks. I
also have a gcc5 install ISO which I need to confirm, but I think I'm good. If
you're good, I'll mark you as a reviewer, integrate, rebuild the world, and see
if a conventional "pkg update" works on my pristine bloody system.
Thanks,
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] 014 and X540 on intel s2600
> On Jun 16, 2015, at 3:44 AM, Tobias Oetiker wrote: > > > To to recap ... x540 10 Gigabit Copper Ethernet ports work on > omnios r014 out of the box. IF the cable is plugged in. Phew. I'm glad this is one less thing for me to deal with after a long weekend trip. Thanks! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] 014 and X540 on intel s2600
Friday Tobias Oetiker wrote: > We are trying to get an intel 10G network interface x540 to work > on omnios r014. We do see the interface with > > $ dladm show-phys > > but it does not show any reaction when we plug an ethernet cable > leading to a 1Gb switch port. It stays 'down' to resolve this ... it turnes out the customer had neglected to plug the network cable in ... and had steadfastly claimed that everything was plugged propperly when we called him. Only today when we called again and another member of staff went to check, he found that no cable was connected to the port ... To to recap ... x540 10 Gigabit Copper Ethernet ports work on omnios r014 out of the box. IF the cable is plugged in. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch t...@oetiker.ch +41 62 775 9902 ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
