Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash
The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which is in turn a downstream of Oracle's, but last synched in 2013 (because Oracle uses hg, and git from hg is annoying). Interesting, wasn't aware of that. So is it really just a matter of mercurial-git conversion, or has the OI/Omni version of pkg diverged too much? if the former, maybe one of the many tools could be leveraged that pull stuff out of hg repos and push it into git? I don't know. I don't do the downstreaming from Oracle... OI does. OK, I will post a query to the OI dev list when I have time. Just running pkg.depotd in the foreground. /usr/lib/pkg.depotd -p 2112 -d blah Port 2112, with blah being a pkgrepo(1M) directory. Neat trick for debugging, thanks. [...] ...but the pkg/server:my-pub instance listens on another port, hence the 404 codes. I'd have to look deeper, and maybe enable more debugging output. The 404 is expected. That was just to show the pkg/1427212657. Going forward, what is the likelihood of OmniOS adopting a more recent version of the Oracle IPS gate? I don't really think I can offer much help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if it fixes that bug. I have enough else pulling at me at the moment I can't look at this deeply right now. Understood. Same here. Thanks for having a look! Regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt When logic and proportion have fallen sloppy dead ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash
On Apr 20, 2015, at 4:38 PM, Volker A. Brandt v...@bb-c.de wrote: Hi Dan! Dug through my mail, and I didn't see this note. I may have lost it, but gmail is usually good about not letting you get rid of mails. :( Well, I sent it to @omniti.com. My guess is you don't see any of my mails because they are filtered away. But no matter, as long as the discuss list works, that's fine. I may have deleted it while reading on my phone (which can happen more than I'd like). The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which is in turn a downstream of Oracle's, but last synched in 2013 (because Oracle uses hg, and git from hg is annoying). Interesting, wasn't aware of that. So is it really just a matter of mercurial-git conversion, or has the OI/Omni version of pkg diverged too much? if the former, maybe one of the many tools could be leveraged that pull stuff out of hg repos and push it into git? I don't know. I don't do the downstreaming from Oracle... OI does. wonder if this bug was around a while, and that's why it's ms.omniti.com instead of omniti-ms, for example? Sounds likely. I wouldn't know. :-) I mention that for the list's benefit, because that decision was made before I arrived at OmniTI. ANYWAY, my toy server with an empty repo had this in its logs: 127.0.0.1 - - [20/Apr/2015:13:32:46] GET /versions/0/ HTTP/1.1 200 179 pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; pkg) Interesting. Where does that log come from? Do you have an Apache with redirect rules sitting in front of your repo? Just running pkg.depotd in the foreground. /usr/lib/pkg.depotd -p 2112 -d blah Port 2112, with blah being a pkgrepo(1M) directory. I did play around with redirects and rewrite rules, but wasn't really happy, so I decided to concentrate on one problem at a time. My Apache logs show similar entries when I tell the IPS client to use port 80 (where an Apache is listening on the pkg server host): 192.168.xxx.xxx - - [20/Apr/2015:17:58:10 +0200] GET /my-repo/versions/0/ HTTP/1.1 404 220 - pkg/1427212657 (sunos i86pc; 5.11 omnios-170cea2; full; pkg) ...but the pkg/server:my-pub instance listens on another port, hence the 404 codes. I'd have to look deeper, and maybe enable more debugging output. Going forward, what is the likelihood of OmniOS adopting a more recent version of the Oracle IPS gate? I don't really think I can offer much help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if it fixes that bug. I have enough else pulling at me at the moment I can't look at this deeply right now. Sorry, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash
On Mon, Apr 20, 2015 at 4:38 PM, Volker A. Brandt v...@bb-c.de wrote: wonder if this bug was around a while, and that's why it's ms.omniti.com instead of omniti-ms, for example? Sounds likely. I wouldn't know. :-) I would know, as I was the one that chose it when I was at OmniTI. :) The various OmniTI extra publishers (those other than omnios) use the pseudo-domain-name style, simply for the high degree of confidence that it is globally unique. I was unaware of the issue with dashes in publisher names, but IIRC way back at the beginning (circa 2011) when we started working on what would become OmniOS, I'm pretty sure there was an omni-os publisher configured. Perhaps the issue was introduced in a later revision (one that's in the OI fork) but only fixed after the last time OI synced their tree. Going forward, what is the likelihood of OmniOS adopting a more recent version of the Oracle IPS gate? I don't really think I can offer much help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if it fixes that bug. As I understand it (someone please correct me if I'm wrong), we cannot use Oracle's pkg-gate unmodified, as it has dependencies on closed bits in Solaris for certain features. Those need to be stripped/modified for non-Solaris use, which is what OI has been maintaining in their fork, thanks mostly to the hard work of Andrzej Szeszo. Anyone interested in helping refresh https://github.com/OpenIndiana/pkg5 from Oracle's gate would benefit both communities. Eric ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash
As I understand it (someone please correct me if I'm wrong), we cannot use Oracle's pkg-gate unmodified, as it has dependencies on closed bits in Solaris for certain features. Those need to be stripped/modified for non-Solaris use, which is what OI has been maintaining in their fork, thanks mostly to the hard work of Andrzej Szeszo. Anyone interested in helping refresh https://github.com/OpenIndiana/pkg5 from Oracle's gate would benefit both communities. Thanks for the info Eric! A quick glance at that URL shows that people are working on it. Last commit was March 9th by Alexander Pyhalov. I'll ping the OI guys as to what kind of effort is needed. Don't hold your breath though. :-) Regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt When logic and proportion have fallen sloppy dead ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash
Hi Dan! This is paraphrased from a mail that I had sent to Dan privately on March 31st. Unfortunately, the problem still persists in 151014. Dug through my mail, and I didn't see this note. I may have lost it, but gmail is usually good about not letting you get rid of mails. :( Well, I sent it to @omniti.com. My guess is you don't see any of my mails because they are filtered away. But no matter, as long as the discuss list works, that's fine. I'm seeing a different variant of this error using a toy repo I set up. It has to be an http repo using pkg.depotd. If I use a file:/// URL, it appears to work. Exactly. Good to know that I am not imagining things. The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which is in turn a downstream of Oracle's, but last synched in 2013 (because Oracle uses hg, and git from hg is annoying). Interesting, wasn't aware of that. So is it really just a matter of mercurial-git conversion, or has the OI/Omni version of pkg diverged too much? if the former, maybe one of the many tools could be leveraged that pull stuff out of hg repos and push it into git? The github URL is https://github.com/omniti-labs/pkg5/ if you wanna poke around in the source we use. NOTE we have per-release branches starting with r151014, but the default master is called omnios because we're a downstream child of another downstream child. Thanks for the pointer, but I guess it would take me ages to spot, let alone fix the bug. I don't know of anyone who uses dashes in their publisher name. Well, now you know. :-) BTW IHAC who uses lots of dashes in lots of publisher names under Solaris... just a matter of taste I guess. wonder if this bug was around a while, and that's why it's ms.omniti.com instead of omniti-ms, for example? Sounds likely. I wouldn't know. :-) ANYWAY, my toy server with an empty repo had this in its logs: 127.0.0.1 - - [20/Apr/2015:13:32:46] GET /versions/0/ HTTP/1.1 200 179 pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; pkg) Interesting. Where does that log come from? Do you have an Apache with redirect rules sitting in front of your repo? I did play around with redirects and rewrite rules, but wasn't really happy, so I decided to concentrate on one problem at a time. My Apache logs show similar entries when I tell the IPS client to use port 80 (where an Apache is listening on the pkg server host): 192.168.xxx.xxx - - [20/Apr/2015:17:58:10 +0200] GET /my-repo/versions/0/ HTTP/1.1 404 220 - pkg/1427212657 (sunos i86pc; 5.11 omnios-170cea2; full; pkg) ...but the pkg/server:my-pub instance listens on another port, hence the 404 codes. Going forward, what is the likelihood of OmniOS adopting a more recent version of the Oracle IPS gate? I don't really think I can offer much help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if it fixes that bug. Regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt When logic and proportion have fallen sloppy dead ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Please update - it's a reboot-your-box one
If you have any of r151006, r151012, or r151014, please update your machines for a reboot-worthy update. A kernel bug was recently found and fixed that COULD cause privilege escalation. To be safe, I built the entirety of illumos-omnios and pushed those (after signing in 012 014) out to their respective repos. The 014 additional brought along a few extra ZFS fixes, and one more mr_sas fix, upstreamed not long after the 014 illumos merge window closed. I'm obtaining a CVE number, but don't have it yet. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] crash dump analysis help
On Apr 20, 2015, at 7:02 AM, Rune Tipsmark r...@steait.net wrote: root@zfs10:/root# uname -a SunOS zfs10 5.11 omnios-10b9c79 i86pc i386 i86pc That's r151012 (modulo today's update... read the list in a bit). Any idea how I can troubleshoot further? Share the dump so people can see it. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] crash dump analysis help
root@zfs10:/root# uname -a SunOS zfs10 5.11 omnios-10b9c79 i86pc i386 i86pc Any idea how I can troubleshoot further? br, Rune From: Dan McDonald dan...@omniti.com Sent: Monday, April 20, 2015 3:58 AM To: Rune Tipsmark Cc: omnios-discuss; Dan McDonald Subject: Re: [OmniOS-discuss] crash dump analysis help What version of OmniOS are you running (uname -a, or cat /etc/release)? Clearly a bad pointer was passed into bzero(). The pointer was 0xec6093a0, according to your panic screen. It COULD be bad HW, but it could also be something more sinister. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Please update - it's a reboot-your-box one
If you have any of r151006, r151012, or r151014, please update your machines for a reboot-worthy update. Done. Absolutely smooth, no problems whatsoever. Regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt When logic and proportion have fallen sloppy dead ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash
On Apr 20, 2015, at 1:11 PM, Volker A. Brandt v...@bb-c.de wrote: Hello all! This is paraphrased from a mail that I had sent to Dan privately on March 31st. Unfortunately, the problem still persists in 151014. Dug through my mail, and I didn't see this note. I may have lost it, but gmail is usually good about not letting you get rid of mails. :( There seems to be a bug in the IPS version that comes with OmniOS. If there is a dash in the publisher name and the repo is accessed via http, it breaks: omnitest# pkg set-publisher -g http://omnios-server:12345/ my-pub pkg set-publisher: Could not refresh the catalog for my-pub http protocol error: code: 400 reason: Bad Request URL: 'http://omnios-server:12345/my-pub/catalog/1/catalog.attrs' It does not matter if the client is OmniOS or Solaris 11.2, it always breaks. I'm seeing a different variant of this error using a toy repo I set up. It has to be an http repo using pkg.depotd. If I use a file:/// URL, it appears to work. The Solaris 11.2 SRU8 /usr/bin/pkg has CLIENT_API_VERSION = 79, whereas the OmniOS /usr/bin/pkg is at CLIENT_API_VERSION = 75. So my guess is that the bug was fixed upstream somewhere between the pkg version shipped with OmniOS 151014 and the one shipped S11.2 SRU 8. The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which is in turn a downstream of Oracle's, but last synched in 2013 (because Oracle uses hg, and git from hg is annoying). The github URL is https://github.com/omniti-labs/pkg5/ if you wanna poke around in the source we use. NOTE we have per-release branches starting with r151014, but the default master is called omnios because we're a downstream child of another downstream child. Has anyone seen this problem before? Or does anyone have an OmniOS system successfully serving IPS packages with a dash in the publisher name? Any and all info gratefully accepted! It is entirely possible that I am doing something wrong, but I don't really know where to look. I don't know of anyone who uses dashes in their publisher name. I wonder if this bug was around a while, and that's why it's ms.omniti.com instead of omniti-ms, for example? ANYWAY, my toy server with an empty repo had this in its logs: 127.0.0.1 - - [20/Apr/2015:13:32:46] GET /versions/0/ HTTP/1.1 200 179 pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; pkg) 127.0.0.1 - - [20/Apr/2015:13:32:46] GET /publisher/0/ HTTP/1.1 200 57 pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; pkg) Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] slow ssh login, maybee to many locales?
Slow ssh logon is almost always reverse DNS problems on the server side. Adding the client to the server's /etc/hosts will usually resolve the problem. -Chip On Sat, Apr 18, 2015 at 10:37 PM, PÁSZTOR György pasz...@sagv5.gyakg.u-szeged.hu wrote: Hi, I faced with that, the login onto my new omnios zone is slow. I tried to debug. Many of the symptoms seemed pretty the same as this: http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/ Also in my case it stopped at the same point: after the kexinit sent. However, on my omnios, the cryptadm list showed this: pasztor@omni:~$ cryptoadm list User-level providers: Provider: /usr/lib/security/$ISA/pkcs11_kernel.so Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so Kernel software providers: des aes arcfour blowfish ecc sha1 sha2 md4 md5 rsa swrand Kernel hardware providers: [---end of output] So, in my case it did not contained the tpm module. I tried the opposite: enabling the tpm module, but nothing changed. (Maybe it become even slower. I did not count the seconds) So, I rewert it back, and run the same truss command, which revealed this: There are tons's of file openings in the /usr/lib/locale dir at that point: 24560: 8.8232 stat(/usr/lib/locale/is_IS.UTF-8, 0x08047D48) = 0 24560: 8.8234 open(/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA, O_RDONLY) = 7 24560: 8.8236 fstat(7, 0x08047658)= 0 24560: 8.8237 mmap(0x, 94904, PROT_READ, MAP_PRIVATE, 7, 0) = 0xFEDE7000 24560: 8.8238 close(7)= 0 ... 24560: 14.5883 open(/usr/lib/locale//el_GR.ISO8859-7/LC_MESSAGES/LCL_DATA, O_RDONLY) = 7 24560: 14.5884 fstat(7, 0x08047678)= 0 24560: 14.6061 read(7, ^ ( ( [EDCD ] ( [E1C1 ].., 82) = 82 24560: 14.6063 close(7)= 0 24560: 14.6065 getdents64(5, 0xFEE04000, 8192) = 0 24560: 14.6069 ioctl(1, TCGETA, 0x08046DBE)Err#22 EINVAL 24560: 14.6069 fstat64(1, 0x08046E00) = 0 24560: 14.6070 brk(0x080689D0) = 0 24560: 14.6071 brk(0x0806A9D0) = 0 24560: 14.6072 fstat64(1, 0x08046D00) = 0 24560: 14.6074 close(5)= 0 24560: 14.6075 write(1, C\n P O S I X\n a f _ Z.., 2891)= 2891 24556: 14.6076 read(3, C\n P O S I X\n a f _ Z.., 5120) = 2891 24560: 14.6077 _exit(0) 24556: 14.6080 brk(0x080D0488) = 0 24556: 14.6082 brk(0x080D2488) = 0 24556: 14.6083 read(3, 0x080CD544, 5120) = 0 24556: 14.6084 llseek(3, 0, SEEK_CUR) Err#29 ESPIPE 24556: 14.6085 close(3)= 0 24556: 14.6296 waitid(P_PID, 24560, 0x080473F0, WEXITED|WTRAPPED) = 0 So, does somebody knows what is happening at that point, why, and how can I fine-tune it? Kind regards, György Pásztor ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] slow ssh login, maybee to many locales?
Hi, I faced with that, the login onto my new omnios zone is slow. I tried to debug. Many of the symptoms seemed pretty the same as this: http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/ Also in my case it stopped at the same point: after the kexinit sent. However, on my omnios, the cryptadm list showed this: pasztor@omni:~$ cryptoadm list User-level providers: Provider: /usr/lib/security/$ISA/pkcs11_kernel.so Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so Kernel software providers: des aes arcfour blowfish ecc sha1 sha2 md4 md5 rsa swrand Kernel hardware providers: [---end of output] So, in my case it did not contained the tpm module. I tried the opposite: enabling the tpm module, but nothing changed. (Maybe it become even slower. I did not count the seconds) So, I rewert it back, and run the same truss command, which revealed this: There are tons's of file openings in the /usr/lib/locale dir at that point: 24560: 8.8232 stat(/usr/lib/locale/is_IS.UTF-8, 0x08047D48) = 0 24560: 8.8234 open(/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA, O_RDONLY) = 7 24560: 8.8236 fstat(7, 0x08047658)= 0 24560: 8.8237 mmap(0x, 94904, PROT_READ, MAP_PRIVATE, 7, 0) = 0xFEDE7000 24560: 8.8238 close(7)= 0 ... 24560: 14.5883 open(/usr/lib/locale//el_GR.ISO8859-7/LC_MESSAGES/LCL_DATA, O_RDONLY) = 7 24560: 14.5884 fstat(7, 0x08047678)= 0 24560: 14.6061 read(7, ^ ( ( [EDCD ] ( [E1C1 ].., 82) = 82 24560: 14.6063 close(7)= 0 24560: 14.6065 getdents64(5, 0xFEE04000, 8192) = 0 24560: 14.6069 ioctl(1, TCGETA, 0x08046DBE)Err#22 EINVAL 24560: 14.6069 fstat64(1, 0x08046E00) = 0 24560: 14.6070 brk(0x080689D0) = 0 24560: 14.6071 brk(0x0806A9D0) = 0 24560: 14.6072 fstat64(1, 0x08046D00) = 0 24560: 14.6074 close(5)= 0 24560: 14.6075 write(1, C\n P O S I X\n a f _ Z.., 2891)= 2891 24556: 14.6076 read(3, C\n P O S I X\n a f _ Z.., 5120) = 2891 24560: 14.6077 _exit(0) 24556: 14.6080 brk(0x080D0488) = 0 24556: 14.6082 brk(0x080D2488) = 0 24556: 14.6083 read(3, 0x080CD544, 5120) = 0 24556: 14.6084 llseek(3, 0, SEEK_CUR) Err#29 ESPIPE 24556: 14.6085 close(3)= 0 24556: 14.6296 waitid(P_PID, 24560, 0x080473F0, WEXITED|WTRAPPED) = 0 So, does somebody knows what is happening at that point, why, and how can I fine-tune it? Kind regards, György Pásztor ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] omnios zone experiences on openindiana
Hi, I do not remember, where I discussed about this topic earlier, but I just wanted to tell a success-story: I had a playground omnios-blody (151013) in a VirtualBox. I upgraded it to the current 151014 LTS. Then I created a zone into it to have a template. Then I migrated this zone to my home nas, which run OpenIndiana 151a9. Everything succeed, but I had some slap on my face to learn things:) So, I thought I share those experiences: At First time I forget to detach the zone. Docs says, you do not have to. But you suck much more if you don't so, detach the zone! ;-) Usual google findings about this topic is original sun/oracle docs, where zfs send has a -rc options. I used -R option. I did not have a sunsol11 playground in the near. And at the attach phase. You will suck! But, one thing which may help: http://everycity.co.uk/alasdair/2011/10/fixing-no-active-dataset-on-zone-attach/ That script helps you to setting zfs property after the migration. After running that script you can mount the ROOT/zbe by hand, as Alisdair writes, and the attach... almost work. I made a mistake, tried the attach with -u, which also exists on oracle/sun docs, but not on the illumos branch, so my openindiana added their own publishers to my zone. So, I attached again, but now with the -n option, which eliminates the checkings. Then I could boot the zone. I fixed the publishers. Then I could clone the zone, so now I can have omnios 151014 lts zones on my openindiana nas. (And I could eliminate also eliminate one virtualbox linux machine, since a native illumos based system is much-much efficient and using fstype=lofs instead of nfs, and an os-level virtualization instead of machine virtualization, etc.) Kind regards, György Pásztor ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] A warning for upgraders with large numbers of BEs
Hi, Dan McDonald dan...@omniti.com wrote at 2015-03-23 16:14: Soon r151014 will be hitting the streets. WHEN THAT DOES, I have to warn people, especially those jumping from r151006 to r151014 about a known issue in grub. The illumos grub has serious memory management issues. It cannot cope with too many boot environment (BE) entries. Sorry for semi-offtopicing the thread, but: Will the lx brand be restored in the upcoming release? Is there a feature map / release plan / anything available? I tried to find information regarding this topic without success. I checked this url: http://omnios.omniti.com/roadmap.php But nothing relevant information was there. It seems outdated / unmaintained. I've just recently find this distro. I used openindiana since Oracle... -- Did what they did to opensolaris -- So, I'm new here, sorry for lame questions. Kind regards, György Pásztor ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
