Re: [OmniOS-discuss] bug in powertop
On Wed, 10 Jun 2015 17:04:20 +0100 Peter Tribble wrote: > > Delete that line in powertop.c and all should be well. > Do I need to build the entire illumos-gate to recompile powertop? > (I get the following as well: > powertop: failed to compile P-states (frequencies) program > powertop: failed to compile C-states (idle power) program > so I'm not sure it's actually functional.) > You need to run powertop either as root or using sudo. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -- /usr/games/fortune -es says: Q: What do little WASPs want to be when they grow up? A: The very best person they can possibly be. pgpb4awfaYBn4.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] ipadm failing after first zone boot
> On Jun 10, 2015, at 14:36, Dan McDonald wrote: > > >> On Jun 6, 2015, at 4:45 PM, Heinz Nikolaus Gies wrote: >> >> I noticed some rather odd behavior, to set up networking I use the following >> commands: >> >> [GZ] dladm create-vnic -l bge0 net4 -p allowed-ips=10.0.0.111/32 >> (do zone creation wait until svc has reached >> svc:/milestone/sysconfig:default) > > I'm assuming you've done a zone boot at this point as well? (You don't say > it, but "reached milestone/sysconfig" suggests you have.) Yup zone boot was done, and I waited till the last milestone was reached (I forgot that before ;) > >> [NGZ] ipadm create-if net4 >> [NGZ] ipadm create-addr -T static -a 10.0.0.111/24 net4/v4 >> ipadm: Could not create address: Operation not permitted on from-gz interface > > That *is* really weird. I'm assuming you can reproduce this bug? In 100% of the tests I’ve had done yes, if it were a one time thing I’d have just doubted myself and wrote it off as me probably having forgotten something. > > Also, have you tried just doing the create-addr w/o the create-if? I'm > pretty sure you can shortcut, and perhaps it works around the not-permitted > problem? That I have not tried but I’ll give it a try, my work around right now is actually doing a full re-boot of the zone so it’s not too huge of a problem, but it looked like a bug > > Thanks, > Dan > signature.asc Description: Message signed with OpenPGP using GPGMail ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] bug in powertop
On Tue, Jun 9, 2015 at 4:45 PM, Michael Rasmussen wrote: > Hi all, > > Anybody able to start powertop using some of the available options? > root@nas:/root# powertop -d 1 > Segmentation Fault (core dumped) > Oh, that's bad. Look at: http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/powertop/common/powertop.c#81 which is: char *optarg; So, when getopt_long parses the arguments and pokes things back into optarg, where's it going to end up? Not the right optarg, hence the SEGV when strtod() is called on the local optarg. Delete that line in powertop.c and all should be well. (I get the following as well: powertop: failed to compile P-states (frequencies) program powertop: failed to compile C-states (idle power) program so I'm not sure it's actually functional.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] bug in powertop
On Wed, 10 Jun 2015 09:34:03 -0500 (CDT) Bob Friesenhahn wrote: > > I have read that powertop uses DTrace probes under Illumos. Does it link > against a dtrace library? Has the interface changed? > If it is linked dynamically to DTrace then you shouldn't see a segmentation fault unless the source does not check for null-pointer references. Statically linked to DTrace and you should not be able to pass the linker stage. > Another possibility is the internationalization changes (from scratch > re-write) in Illumos. Check the locale settings. Locale settings could > influence string to decimal conversion. > This could be an explanation but I doubt it. My default locale is C and I have run some test with LANG configured to en, en_US, en_UK but without any change. My best guess is a bug in the code so I will fetch the source and run it through gdb. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -- /usr/games/fortune -es says: Never keep up with the Joneses. Drag them down to your level. -- Quentin Crisp pgpOT7GzP42Lc.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] bug in powertop
On Tue, 9 Jun 2015, Zach Malone wrote: This sounds like a libc or kernel change, but I can't imagine why it would show up on both 012 and 014. Maybe someone with a working build environment can dig further? I have read that powertop uses DTrace probes under Illumos. Does it link against a dtrace library? Has the interface changed? Another possibility is the internationalization changes (from scratch re-write) in Illumos. Check the locale settings. Locale settings could influence string to decimal conversion. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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 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?
> 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.
In The Beginning, it was just "BUILD_DEPENDS" and "DEPENDS". The
former obviously being build-time, the latter run-time. But for a
while, as we started developing OmniOS, we had a hybrid build system
(what would eventually become ms.omniti.com) that could build either
SVR4 or IPS packages, depending on the desired target. That's where
the "_IPS" variants came in, to distinguish from the (now defunct)
"_SVR4" ones. We didn't really know about or grok pkgdepend in the
beginning.
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.
>
>> Also, NSPR: there's version changes for the package along with the
>> compiler change. Was that intentional? I don't much care either way,
>> just curious if something slipped in by mistake.
>
> Threw in the update to see if it was gcc51 ready, it wasn't, but I kept the
> updates in anyway.
Understood.
Eric
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] FiFo on OmniOS
> On Jun 8, 2015, at 5:01 PM, Heinz Nikolaus Gies wrote: > > Hi Stevan, > yap I suppose that would be great but I haven’t yet figured out the ipgk > build system (any help appreciated ;). For now it’s manual compilation on > OmniOS (not as horrible as it sounds!) or using a SmartOs system with pkgin. When you're closer to ready, I can package it up -- this wouldn't be part of OmniOS's repo, but I suspect it'd have a nice home in the "ms.omniti.com" repo. I'll see. Dan ___ 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 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.)
> A lot of these build scripts predate the introduction of
> pkgdepend/pkglint, and IMO the changes where it's just updating
> DEPENDS_IPS could just be a straight removal of the entire DEPENDS_IPS
> line. pkgdepend should easily take care of any/all ELF dependencies
> now.
pkgdepend, OTOH, runs.
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.
> Also, NSPR: there's version changes for the package along with the
> compiler change. Was that intentional? I don't much care either way,
> just curious if something slipped in by mistake.
Threw in the update to see if it was gcc51 ready, it wasn't, but I kept the
updates in anyway.
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] ipadm failing after first zone boot
> On Jun 6, 2015, at 4:45 PM, Heinz Nikolaus Gies wrote: > > I noticed some rather odd behavior, to set up networking I use the following > commands: > > [GZ] dladm create-vnic -l bge0 net4 -p allowed-ips=10.0.0.111/32 > (do zone creation wait until svc has reached svc:/milestone/sysconfig:default) I'm assuming you've done a zone boot at this point as well? (You don't say it, but "reached milestone/sysconfig" suggests you have.) > [NGZ] ipadm create-if net4 > [NGZ] ipadm create-addr -T static -a 10.0.0.111/24 net4/v4 > ipadm: Could not create address: Operation not permitted on from-gz interface That *is* really weird. I'm assuming you can reproduce this bug? Also, have you tried just doing the create-addr w/o the create-if? I'm pretty sure you can shortcut, and perhaps it works around the not-permitted problem? Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Zpool export while resilvering?
On Wed, Jun 10, 2015 at 4:09 AM, Robert A. Brock < robert.br...@2hoffshore.com> wrote: > What did you use to flash them? Fwflash just gives an error about > firmware file being too large. > Santools. -Chip > > > *From:* Schweiss, Chip [mailto:c...@innovates.com] > *Sent:* 09 June 2015 21:25 > *To:* Robert A. Brock > *Cc:* omnios-discuss > *Subject:* Re: [OmniOS-discuss] Zpool export while resilvering? > > > > I went through this problem a while back. There are some gotchas in > getting them back online and firmware upgraded. The is will not talk to > the drive until it has its firmware upgraded or cleared from the fault > database. > > This drives will not flash with multipath enabled either. > > I ended up clearing the fault manager's database, disabling it and > disconnecting half the SAS cables to get them flashed. > > -Chip > > > > > 2H Offshore Engineering Ltd | Registered in England No. 02790139 | > Registered office: Ferryside, Ferry Road, Norwich NR1 1SW. > > > 2H Offshore is an Acteon company specializing in the design, monitoring > and integrity management of offshore riser and conductor systems. Acteon is > a group of specialist international engineering companies serving the > offshore oil and gas industry. Its focus is on subsea services spanning the > entire life of field. For more information, visit www.acteon.com > > > The information in and/or accompanying this email is intended for the > use of the stated recipient only and may be confidential and/or privileged. > It should not be forwarded or copied nor should its contents be disclosed > in any manner without the express consent of the sender/author. Any views > or opinions presented are solely those of the author and do not necessarily > represent those of 2H. > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Wiki change
Using dsk for kvm seems to be working for me so far, but I've nothing to compare it with - some of the other guys thought there may be a performance penalty? On 10/06/2015 08:23, Nikola M wrote: On 06/ 3/15 01:17 PM, Graham Stephens wrote: "Note that adding a raw volume to a zone has implicit security risks, even if the volume doesn't correspond to a physical device. In particular, the zone administrator could create malformed file systems that would panic the system when a mount is attempted." It is for Zones, right? Not to let them use rdsk. On the other hand I need to use raw disk for Virtualbox to make vmdk out of zfs volume. (and for kvm?) Wonder about recommendations for exporting volume to ISCSI. ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] kvm networking
Thanks Dominik, that fits with the way it worked best during my experimentation. The unix socket is a good idea, I had wondered how to get round that. It turns out that my issue was a complete newb one - I used tcpdump from within the guest and found the packets were reaching the OS after all. I had used the CLI to add rules to iptables on the guest for the mail server, not realising that it was dumb and was appending the rules AFTER the default-supplied REJECT rule. After re-writing and reloading the ruleset, all is now well. Thanks for the assistance and the tips. --- On 09/06/2015 23:32, Dominik Hassler wrote: Graham, With "dedicated vnic" I meant that you don't apply an address for it within the zone. The zone is aware of it but you should not set it up. Sorry if my description was a bit misleading... If you want to use VNC you'll have to setup a second vnic in the zone config and apply an address for that one or use a unix socket for VNC which is my preferred option. Adding the vnics as network resources is perfectly fine. ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Zpool export while resilvering?
What did you use to flash them? Fwflash just gives an error about firmware file being too large. From: Schweiss, Chip [mailto:c...@innovates.com] Sent: 09 June 2015 21:25 To: Robert A. Brock Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Zpool export while resilvering? I went through this problem a while back. There are some gotchas in getting them back online and firmware upgraded. The is will not talk to the drive until it has its firmware upgraded or cleared from the fault database. This drives will not flash with multipath enabled either. I ended up clearing the fault manager's database, disabling it and disconnecting half the SAS cables to get them flashed. -Chip ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Wiki change
On 06/ 3/15 01:17 PM, Graham Stephens wrote: I am going off the Oracle docs here: http://docs.oracle.com/cd/E19253-01/819-5461/gbebi/index.html which state: "Note that adding a raw volume to a zone has implicit security risks, even if the volume doesn't correspond to a physical device. In particular, the zone administrator could create malformed file systems that would panic the system when a mount is attempted." It may be overkill, but considering my initial problem was one of a system crash, it stuck in my head. It is for Zones, right? Not to let them use rdsk. On the other hand I need to use raw disk for Virtualbox to make vmdk out of zfs volume. (and for kvm?) Wonder about recommendations for exporting volume to ISCSI. ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
