Re: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha

2017-03-02 Thread Stephan Budach


- Ursprüngliche Mail -
> Von: "Dan McDonald" 
> An: "Stephan Budach" 
> CC: "omnios-discuss" , "Dan McDonald" 
> 
> Gesendet: Donnerstag, 2. März 2017 15:18:14
> Betreff: Re: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha
> 
> 
> > On Mar 2, 2017, at 2:29 AM, Stephan Budach 
> > wrote:
> > 
> >>> 
> >>> Next is some kind of stack trace and finally
> >>> 
> >>> BTX halted
> >> 
> >> Is that Xen-based?
> >> 
> >> Dan
> >> 
> >> 
> > 
> > Yes, it is.
> 
> Doug Hughes just showed me the same thing, and I'm pretty sure he's
> Xen too.
> 
> I wonder if I need to add BE items to the ISO.  I think instead of
> /kernel/i86pc/kernel/amd64/unix, you Xen folks may need to boot
> /platform/i86{hvm,xpv}/kernel/amd64/unix instead.  Worst case is I
> have to build a distinct xpv or hvm ISO.  :-P
> 
> Like I said, today's going to be a reading day, but I'll add that to
> my work on build_iso.sh, as that's where it belongs.
> 
> Thanks,
> Dan
> 
> 

Great - that would be a blast!

Happy reading,
Stephan


smime.p7s
Description: S/MIME cryptographic signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha

2017-03-02 Thread Doug Hughes



On 3/2/2017 9:18 AM, Dan McDonald wrote:

On Mar 2, 2017, at 2:29 AM, Stephan Budach  wrote:


Next is some kind of stack trace and finally

BTX halted

Is that Xen-based?

Dan



Yes, it is.

Doug Hughes just showed me the same thing, and I'm pretty sure he's Xen too.

I wonder if I need to add BE items to the ISO.  I think instead of 
/kernel/i86pc/kernel/amd64/unix, you Xen folks may need to boot 
/platform/i86{hvm,xpv}/kernel/amd64/unix instead.  Worst case is I have to 
build a distinct xpv or hvm ISO.  :-P

Like I said, today's going to be a reading day, but I'll add that to my work on 
build_iso.sh, as that's where it belongs.

Thanks,
Dan




I'm on libvirt/KVM/qemu
If it matters, it's an AMD processor (but I seriously doubt it)


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha

2017-03-02 Thread Dan McDonald

> On Mar 2, 2017, at 2:29 AM, Stephan Budach  wrote:
> 
>>> 
>>> Next is some kind of stack trace and finally
>>> 
>>> BTX halted
>> 
>> Is that Xen-based?
>> 
>> Dan
>> 
>> 
> 
> Yes, it is.

Doug Hughes just showed me the same thing, and I'm pretty sure he's Xen too.

I wonder if I need to add BE items to the ISO.  I think instead of 
/kernel/i86pc/kernel/amd64/unix, you Xen folks may need to boot 
/platform/i86{hvm,xpv}/kernel/amd64/unix instead.  Worst case is I have to 
build a distinct xpv or hvm ISO.  :-P

Like I said, today's going to be a reading day, but I'll add that to my work on 
build_iso.sh, as that's where it belongs.

Thanks,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] Change in uname behavior between r151014 and r151020?

2017-03-02 Thread N. Nadine Miller
On Wed, Mar 1, 2017 at 10:39 AM, Dan McDonald  wrote:
>
>> On Mar 1, 2017, at 8:56 AM, N. Nadine Miller  wrote:
>>
>> I installed pkgsrc some time ago and attempted to upgrade this
>> morning. When I attempted to update the pkg tools, it gave me an error
>
> What exactly do you mean when you says "update the pkg tools"?

Joyent has a process to upgrade pkgsrc, one of those steps is:

PKG_PATH=http://pkgsrc.joyent.com/packages/SmartOS/2016Q4/x86_64/All
pkg_add -U pkg_install pkgin

This failed with an error that I mistakenly took to mean that my
kernel was not 64-bit. After looking at uname, and then isainfo, I
realized that the error was due to the Joyent pkgsrc I have installed
being 32-bit and the upgrade I attempted to install being 64-bit.

This has nothing to do with how uname behaves, which triggered me to post.

>> regarding 32-bit vs 64-bit, so reflexively I checked 'uname' output to
>> verify I hadn't broken my recent update to r151020.
>>
>> I discovered that 'uname' incorrectly reports that I have a 32-bit
>> version of OmniOS:
>>> root@jarvis:/opt# uname -a
>>> SunOS jarvis 5.11 omnios-bed3013 i86pc i386 i86pc
>
> That (mis)behavior has always been there.

Thanks for verifying that. I hadn't realized that has always been the
behavior, OmniOS generally "just works" so I had not run into this
oddity previously, and my incorrect assumption in the subject.

[...]
> Also correct -- the binaries in /sbin are compiled 32-bit for ancient 
> reasons.  And you may also notice that a binary in /usr/{bin,sbin} is also 
> 32-bit, but there are /usr/{bin,sbin}/{i86,i386,amd64} versions, which are 
> auto-switched-into the correct version based on isainfo:
>
> r151014(~/ws/illumos-omnios)[0]% ls -lt /usr/sbin/dtrace
> -r-xr-xr-x  77 root bin12768 Feb  3  2015 /usr/sbin/dtrace*
> r151014(~/ws/illumos-omnios)[0]% ls -lt /usr/sbin/*/dtrace
> -r-xr-xr-x   1 root bin57920 Dec 31 01:50 /usr/sbin/amd64/dtrace*
> -r-xr-xr-x   1 root bin50924 Dec 31 01:50 /usr/sbin/i86/dtrace*
> r151014(~/ws/illumos-omnios)[0]%

I was aware of this, thanks to the thorough documentation on how this
works to provide both versions, hence my confusion about uname.

Thanks for the response.

=Nadine=
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] Improved, but still alpha, ISO installer

2017-03-02 Thread miras

On 2017-03-02 03:40, Dan McDonald wrote:

2.) Thanks to IRC user "thebug" for confirming this, but it now has
sufficient bugfixes (thanks esp. to Delphix for PR-ing an illumos 
fix into illumos-omnios) to detect and install vioblk devices, at
least in a SmartOS KVM guest.

This fix has not solved the problem with qemu. First disk is still 
mapped by the kernel to the last disk so /dev/dsk/1 and /dev/dsk/n is 
pointing to the same physical disk (n is the number of last disk).


Apart from this I also noticed that diskinfo only lists the last disk - 
perhaps as a consequence of the kernel is mapping /dev/dsk for first and 
last disk to the same physical disk.


--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--



This mail was virus scanned and spam checked before delivery.
This mail is also DKIM signed. See header dkim-signature.

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss