Re: [OpenIndiana-discuss] Split-root installations
On Tue, Nov 26, 2013 at 7:07 PM, Jim Klimov jimkli...@cos.ru wrote: On 2013-11-26 17:25, Jim Klimov wrote: On 2013-11-17 03:50, Jim Klimov wrote: For years I've mentioned split-root installations of Solaris-like systems in such a way that the root filesystem (the BE) is represented by several datasets, such as a split-off /usr dataset. Also there may be some datasets shared between boot environments, such as the sinks for logs and crashdumps, and not all of these are required to live on the rpool at all. There are cases when all such tweaks may be desirable. WARNING As discussed in another thread, it was discovered that the SMF methods for network/physical (both :default and :nwam) use many programs from /usr, and are executed before the /usr filesystem is actually mounted in case of a split-root installation. This tanks the NWAM setups, but the default ones (based on static files in /etc) succeeds for both DHCP and completely static addressing. I hope to fix this somehow, but a head-on approach failed: the root filesystem and other FS services depend on svc:/system/identity:node (indirectly via svc:/system/metainit:default) and that depends on svc:/network/physical... loop and maintenance... Disabling the metainit service does not help fix the dependency_cycle condition :\ A similar problem is logged in iptun service as well: # grep 'not found' /etc/svc/volatile/*log /etc/svc/volatile/network-iptun:default.log:/lib/svc/method/net-iptun: line 81: /usr/bin/cut: not found /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical: line 722: /usr/bin/nawk: not found /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[733]: /usr/bin/sort: not found [No such file or directory] /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical: line 733: cat: not found /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[733]: /usr/bin/nawk: not found [No such file or directory] /etc/svc/volatile/network-physical:default.log:/lib/svc/method/net-physical[317]: /usr/bin/cut: not found [No such file or directory] ... But it does at least depend on physical and if that would be fixed by revised dependencies (to run when /usr is properly present) - so should be iptun. cut, cat and grep are ksh builtins. Use builtin cmdname (run builtin --man to read details) to enable them by default and then remove the absolute paths so the shell doesn't search PATH for them. Most nawk usage can be replaced by ksh pattern matching, leaving sort(1) as the only command to worry about. Irek ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Install OpenIndiana in an UFS root
On Mon, Sep 9, 2013 at 9:32 PM, Richard Elling richard.ell...@richardelling.com wrote: On Sep 9, 2013, at 11:09 AM, Simon Toedt simon.to...@gmail.com wrote: On Mon, Sep 9, 2013 at 7:52 PM, Peter Tribble peter.trib...@gmail.com wrote: Hi, topic says it all. I want to install OpenIndiana on a UFS filesystem. No typo. I do not want to use ZFS on my boot disk. Can you choose what filesystem you want to use for your root during installation? Not on OpenIndiana, the whole of packaging etc essentially requires ZFS root - so the same limitation will likely apply to any distro using IPS. You can install Tribblix to ufs; I'm not aware of any other distro that offers it as an option. (You might have some joy with OpenSXCE, although that uses the same Caiman installer as OI so intercepting it might be tricky.) Seriously, though, I would love to know *why* you don't want to install to ZFS. I can think of several reasons myself (which is why I added the option to Tribblix) but this is quite a specialist area, so what's your use case? Running with less memory maybe? ZFS has a well-deserved reputation for being memory hungry, something which keeps Solaris and Illumos out of the cloud business - as the Amazon sales people say you can have six Linux VMs with ext4fs for one Solaris VM with ZFS in the same memory footprint. Sounds like FUD from a Joyent competitor. Memory is used for cache in both cases, so ext4 obviously does a worse job caching than ZFS. I would not call this FUD. It's a real life observation that I can have four VMware VMs with Suse Linux running in parallel very smoothly, including compiling large projects like the NIH toolchain (blast etc) without pain. Running just two Solaris 11 or Openindiana VMs on the same machine turns the box into a living hell. The same problem applies to cloud installations where Solaris/Illumos with ZFS are a serious *PAIN* unless you invest a lot of money. After all the total cost of ownership running Solaris/Illumos VMs is significantly higher than doing the same with Linux because of that 'little detail' (and no, memory isn't cheap - not if you multiply the 4GB extra with 4096 nodes to ZFS'tify, not always can more modules be added and who pays the extra juice to drive the modules? Memory consumes power, too) IMO the big problem here is the *denial* that this is a problem. Each time the issue comes up (which is quite often) its countered with arguments like ZFS is (more) reliable or ZFS has snapshots, which may only of secondary concern in cloud applications. Irek ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On Mon, Nov 5, 2012 at 7:55 PM, Apostolos Syropoulos asyropou...@yahoo.com wrote: https://mail.gnome.org/archives/distributor-list/2012-November/msg2.html The GNOME community today announced the EOL of their fallback mode, These people have created a desktop for Linux and they do not care about anything else. Unfortunately, this happens with many projects. So either you Linuxize your OS or it drops dead... locale_t/newlocale()/uselocale() and the *_l() apis are hardly Linuxize your OS, they are POSIX. I talked to the Gnome people about this issue. It seems the initial consumers are xml/xsl processing (e.g. xml/xsl @lang and sort directives), which is used *everywhere* and GtkCalendar. The other point was that the locale_t functions are used in shared libraries, which should be able to do locale processing in all locales the user wants, but should not change the per process global locale to avoid race conditions with other shared libraries. Stubs won't be allowed, too. configure will just fail if they detect a stub which still uses or relies on setlocale(). A.S. -- Apostolos Syropoulos Xanthi, Greece ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss Irek ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [developer] Gnome and the future
On Fri, Nov 2, 2012 at 6:15 AM, Alex Caudill alex.caud...@gmail.com wrote:
On 11/1/12, Garrett D'Amore garr...@damore.org wrote:
If this is holding up someone else who wants to do real work of porting
dependency software (Gnome 3, etc.) contact me off list and I'll see if I
can either allocate some weekend/evening time to do the work myself,
or provide guidance to someone else who wants to do it.
- Garrett
As a stopgap, it's trivial to write stubs for the *_l functions. For example:
int strcoll_l(const char *l, const char *r, locale_t loc) {return
strcoll(l, r);}
They all follow this pattern. It's not a real solution but I found it useful.
This is useless because you still do not have newlocale(), duplocale()
or uselocale() which create or use the locale_t object.
The point of the new apis is that you can have an unlimited number of
locale_t objects, all with different properties. As side effect
different threads can use different locale_t objects, giving threads
the ability to run in different locales. But this feature is NOT
limited to per-thread locales as some people may think.
Irek
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [developer] Gnome and the future
On Sun, Nov 4, 2012 at 9:58 PM, Garrett D'Amore garrett.dam...@gmail.com wrote: the original poster was just offering a band aid not a real solution. please keep that in mind before you crucify him. I know. My point is that the bandaid is likely causing more trouble than just waiting for the real solution to appear. Sent from my iPhone On Nov 4, 2012, at 12:01 PM, Irek Szczesniak iszczesn...@gmail.com wrote: On Sun, Nov 4, 2012 at 4:17 PM, Alex Caudill alex.caud...@gmail.com wrote: On Sun, Nov 4, 2012 at 9:46 AM, James Carlson carls...@workingcode.com wrote: On 11/04/12 09:06, Irek Szczesniak wrote: This is useless because you still do not have newlocale(), duplocale() or uselocale() which create or use the locale_t object. Those can be dummied out as well. For example: http://git.musl-libc.org/cgit/musl/tree/src/locale/duplocale.c http://git.musl-libc.org/cgit/musl/tree/src/locale/freelocale.c http://git.musl-libc.org/cgit/musl/tree/src/locale/newlocale.c http://git.musl-libc.org/cgit/musl/tree/src/locale/setlocale.c I'm actually using this code nearly verbatim on OpenIndiana. The point of the new apis is that you can have an unlimited number of locale_t objects, all with different properties. As side effect different threads can use different locale_t objects, giving threads the ability to run in different locales. But this feature is NOT limited to per-thread locales as some people may think. I think the underlying point that the previous poster was making was that for a significant number of users, the desktop environment is launched with the per-process locale set correctly, and the user happily spends all of his time in that single locale. Being able to switch locales on a thread-by-thread basis is certainly nifty, and is perhaps useful in some service providing scenarios (e.g., a web server), but it's quite unclear at least to me how it'd be very much helpful to build a window manager. Perhaps there are multi-lingual people who really do need to have a window manager that can decorate each window differently ... but really? I just wanted to share an approach for Getting This Stuff To Work(TM). How is this going to work when do run in one locale and do towctrans_l() in a different locale? Or use the collation order of de_DE.UTF-8 while the main locale is en_US.UTF-8? There are so many cases where this is going to fail or going to introduce subtle, stupid or plain dataloss bugs that it hurts. Irek --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-6ce4c888 Modify Your Subscription: https://www.listbox.com/member/?; Powered by Listbox: http://www.listbox.com --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175106-197fca96 Modify Your Subscription: https://www.listbox.com/member/?member_id=21175106id_secret=21175106-3d886b59 Powered by Listbox: http://www.listbox.com Irek ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Gnome and the future
On Wed, Oct 31, 2012 at 2:35 PM, Jonathan Adams t12nsloo...@gmail.com wrote: from what I remember of the conversations of the time, we cannot move to Gnome 3 because of certain Linux dependencies ... Gnome 2 is no longer changing, and no longer being patched ... The problem with Gnome 3 is AFAIK mostly a problem of Illumos libc since Gnome 3 intends to move to use the ..._l() apis (e.g. strcasecmp_l(), isalnum_l(), ...) which are not present in Illumos libc. FreeBSD was confronted with the same problem (that major toolkits, including Gnome3 and Qt) and desktops are going to mandate the *_l() apis) and just did the work - see http://freebsdfoundation.blogspot.de/2011/09/following-project-update-was-written-by.html Irek ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Solaris cp problems
On Mon, Sep 24, 2012 at 12:09 PM, Sebastian Gabler sequoiamo...@gmx.net wrote: Hi, I am facing problems with the solaris cp command: $ usr/bin/cp -pr sourcedir . is raising the following errors: cp: cannot create ./SubdirOfTargetDir too many open files cp: cannot open SomeFileInSubDirofSourceDir too many open files cp: Failed to preserve extended system attributes of directory Any idea how to fix that on 5.11 oi_151a i86pc i386 i86pc Solaris? Sounds like your (bash) shell is leaking file descriptors. What does pfiles $$ say? Irek ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] NFS hidden files
On Tue, Jun 5, 2012 at 8:57 AM, Gabriele Bulfon gbul...@sonicle.com wrote: Hi, On NFS mounted file systems I often happen to find daemons of the client complaining about the hidden .nfsxxx files appearing and disappearing. These are often annoying. Is there any way to let the server completely hide these files to the client, and just keep them on the server file system for his own duties? Thanx for any help Gabriele. Which NFS version do you use? I might be wrong but AFAIK NFSv4 dropped the dreaded .nfs* files. Irek ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
