Re: [osol-discuss] inode numbers on ZFS
Daniel, To clear up a misconception about MTB UFS. The maximum density of inodes that can be in a MTB UFS filesystem is 1 inode per megabyte of space. This does not mean that a megabyte of space is used for every file. It simply means you cannot have more than a million or so files per terabyte of storage. The reason for this is simple, it could take days or weeks to fsck the filesystem. sarah Daniel Rock wrote: [EMAIL PROTECTED] schrieb: ZFS is a 128 bit filesystem, isn't it? Depends on whether it's large file aware or not, I'd say. (the ino field in stat64 is 64 bits) So to fully utilize a ZFS file system the average file size has to be 16 EB? People are already moaning today that on MT-UFS the average file size has to be 1 MB... I hope it is just an interface limitation and that ZFS's internals don't impose such a limit. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Project Proposal- FUSE on Solaris
I'd like to propose a FUSE on Solaris project, the porting of the freeBSD version of FUSE, http://fuse4bsd.creo.hu, to Solaris. FUSE is Filesystem in User Space. It provides a simple interface to allow implementation of a fully functional filesystem in userspace. FUSE originates from the Linux community and is included in the Linux kernel (2.6.14+). Many examples of FUSE filesystems can be found here: http://fuse.sourceforge.net/wiki/index.php/FileSystems It is not clear what, if any, community this could live under. The 3 current filesystem communities in OpenSolaris are NFS, UFS and ZFS. Since this doesn't quite fit any of them the proposal is that this project would live independently. Initial Project leaders: Mark Phalan Sarah Jelinek Gerard Cerchio, [EMAIL PROTECTED] Csaba Henk, [EMAIL PROTECTED] Regards, Sarah Jelinek ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Dwarf GUI Demo available
Hi All, For those who might be interested to see how the Dwarf GUI is progressing, we have created a binary package (X86) which is a snapshot of the latest development code. Package can be downloaded from here: http://opensolaris.org/os/project/caiman/files/SUNWgui-install.pkg To install and run: $> pkgadd -d SUNWgui-install.pkg $> install-lan install-lan is the initial pre-install screen and will take care of chain loading the keyboard-layout program and finally the actual install program itself (gui-install). gui-install hides until it receives SIGUSR1, which the keyboard-layout program sends it. Now for the usual disclaimers… * This demo does not do an install or upgrade. It is simply a GUI demo to show the new look and feel for the Caiman GUI's. * This is code under very heavy development. There is lots of stuff that doesn't work yet or hasn't been implemented. If you think you see a bug(and you will), chances are we are aware of it :-) . This is pre-pre-pre Alpha. * Comments/suggestions/ideas are welcome. These should be sent to [EMAIL PROTECTED] We will also update the available demo apps on the Dwarf Caiman demo page as regularly as possible: http://opensolaris.org/os/project/caiman/Dwarf/Dwarf_Demo/ Happy demo'ing! thanks, Dwarf Caiman team ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] sol-nv-b70-x86-dvd-iso zip files failed to download with download mgr
Hi John, snv_70 is being respun to 70a. But, that respin isn't complete yet. I imagine it will be available mid week. Regards, sarah *** John Brewer wrote: > The files for snv_70 sol-nv-b70-x86-dvd-iso zip files fail to down load with > download manager? > Also wasn't the the snv_70 was respun and it was going to be the snv_70b > version? > > > This message posted from opensolaris.org > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Java Server on nv_69
W. Wayne Liauh wrote: >> Unfortunately many authors seem to live under a major >> rock. There isn't >> much Sun can do about it. >> >> Matthew >> >> > > Actually Sun publishes this book and Sun's company logo prominently displays > on the book cover. Sun's people had every right to dictate what should be > included in this book. > > However, hindsight is always 20/20. Two (or may be three) years ago, who in > any reasonable mind could have anticipated that Solaris would work so > powerfully on X86/64 machines? Now even IBM has to roll into the Solaris > camp. It is easy (for me) to criticize that someone might have screwed up, > but the truth is, things are happening beyond anyone's wildest contemplation. > This omission interestingly enough serves a very powerful testimony. > > BTW I installed nv_70 last night. It did have a major problem--I was not > able to preserve the installed slices. Perhaps someone can tell me what I > did wrong. But at least I am able to rid of the crazy gnome cursor behavior > of nv_69. > The new installer in nv70, SXDE3, doesn't have the option to preserve slices with initial install. the upgrade path should preserve any data you have on your system. sarah > > > This message posted from opensolaris.org > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Hi Richard and All, Just a few comments inline... specific to the steps we took in the Caiman installer related to this discussion. >>> Oh C'mon. 512Mb is not enough to run Windoze XP >>> reasonably - even if >>> you can actually install it. With 1Gb memory >>> >> DIMMs >> >>> around $50 (or >>> less), expecting to run a state-of-the-art OS in >>> 512Mb is "absolutely >>> unacceptable". If you're serious about >>> (Open)Solaris, then you're >>> serious about your hardware. >>> >> We should never, under any circumstances, defend >> regression. >> >> Regression is an error. A severe and serious error. >> Dealing with regression has been one of the main >> selling points of Solaris. If Solaris starts >> regressing now, it will have lost one of the most >> crucial competetive edges. >> >> We didn't regress with Dwarf Caiman. We are within the existing memory checks that the Solaris installer has had in them for some time. This is our current requirements: 1. SXDE3 (Dwarf)- 786MB - we do exit out if the user doesn't have enough memory. We tell them to go to the text based installer. Now, 768 is a high limit for Dwarf. We know we can run under less memory, but not on any reasonable boundary where we can lower this requirement at this time. But, we are working on this. 2. SXCE - Interactive GUI - 768MB(same as it has been for a long time) 3. Text installer - windows based - 512MB 4. Console based text installer - > 256MB - its not quite 256MB any longer. Not sure exactly the numbers though. >> We should also stop defending every bad decision and >> hiding behind "engineering" for everything that just >> plain isn't right: >> >> making that installer Java-based and Java-dependent >> was just plain bad decision and it caused regression. >> Rather than hiding behind claims that Java is great >> and that it's "engineering", the responsible >> person(s) should admit the error and fix it. >> > > With Dwarf and subsequent Caiman projects we have moved from the Java based GUI to Gnome and C. This should help some, but it doesn't mitigate all the size issues in the miniroot. > No disagreement with most of that, except that I'm not sure I see > increases in memory requirements (even for the duration of installation) > as regression as such, even if they may a real obstacle. Unless of course > working on a specified minimum configuration is a distro objective that was > violated. > > I see a lot of tradeoffs here (ease of use, flexibility, speed, minimum > hardware requirements, development resources needed to optimize the > balance of the previous, etc). The present situation may suck, but a > balance that would satisfy all interests may not be feasible. > > Or to put it another way, for whatever you want, what would you be > willing to give up? :-) > > Part of the problem may be RAM-resident miniroot bloat. Seems to me > that only volatile data _needs_ to live there; everything else could be > on the installation media. However, optical media is slow in the face > of a lot of seeks. Dividing miniroot space requirements into volatile > data vs cache for performance might help; the latter could be built in > increments based on available resources, so that a system with ample RAM > could install very quickly, but a slimmer system would still install, if > slowly. That is, divide the possible miniroot contents into multiple > cpio (or tar, as you prefer) archives on the installation medium, grouped > so the most benefit comes with the initial increments. Depending on > how much RAM is available, load zero or more of those into the miniroot > (over and above the skeleton needed to hold e.g. device files, symlinks, > directories, config files needed during installation, etc); set $PATH so > that those tools would be found first on the miniroot, and if not there, > on fully-populated versions of the miniroot directories stored on the > installation media. RPATH would be set in the executables to look for > libraries similarly. > > Actually, what you describe is what we do, partially. As part of the work on Dwarf I separated out what needed to be in the part we call the 'miniroot', x86.miniroot archive, and created several new archives that hold the data that may or may not be used depending on the path the user chooses for installation. We unpack only the archives necessary. This helps with the RAM situation. We no longer load Java when it isn't needed. We don't load Gnome when the user has chosen the Java GUI. But, we don't, at this time, run anything from the media until much later for the Tools install. This is something we are looking in to doing. As you note, there may be performance issues with this approach. > A modular installer could also lend itself to both flexibility (character vs > GUI vs answering as much as possible from site config/policy store) and to > having no more of itself resident at any given time than reasonably necessary. >
Re: [osol-discuss] Memory requirements to install Solaris
William Pursell wrote: > On 8/25/07, Dev Mazumdar <[EMAIL PROTECTED]> wrote: > >>> On 8/25/07, Dev Mazumdar <[EMAIL PROTECTED]> wrote: >>> I have a laptop with 512MB RAM and even Windows >>> Vista happily installs on this however Solaris won't >>> saying that it needs 768M to install Developer >>> Express. I even tried installling Solaris Express and >>> it hangs trying to load up Java. >>> Is there any way to get Solaris on this machine? >>> have you tried the text based install? >>> >>> nacho >>> ___ >>> opensolaris-discuss mailing list >>> opensolaris-discuss@opensolaris.org >>> >> Yes I've tried text based install. I verified that 512MB ram is not >> sufficient for B70. >> >> This memory requirement is absolutely unacceptable. >> >> > > Replace unacceptable with insane. I have 512MB in my Ultra 2 and can't > upgrade the memory - how am I supposed to install B70? > This was fixed in b72 and b70a. I believe b70a is available. 512MB does work now for the text based installer. This was a temporary situation due to the increase in miniroot size from the Gnome pkgs. This has been fixed. Please try b70a and let me know if you have issues. Regards, sarah *** > William > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory requirements to install Solaris
Sarah Jelinek wrote: > William Pursell wrote: > >> On 8/25/07, Dev Mazumdar <[EMAIL PROTECTED]> wrote: >> >> >>>> On 8/25/07, Dev Mazumdar <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>> I have a laptop with 512MB RAM and even Windows >>>>> >>>>> >>>> Vista happily installs on this however Solaris won't >>>> saying that it needs 768M to install Developer >>>> Express. I even tried installling Solaris Express and >>>> it hangs trying to load up Java. >>>> >>>> >>>>> Is there any way to get Solaris on this machine? >>>>> >>>>> >>>>> >>>> have you tried the text based install? >>>> >>>> nacho >>>> ___ >>>> opensolaris-discuss mailing list >>>> opensolaris-discuss@opensolaris.org >>>> >>>> >>> Yes I've tried text based install. I verified that 512MB ram is not >>> sufficient for B70. >>> >>> This memory requirement is absolutely unacceptable. >>> >>> >>> >> Replace unacceptable with insane. I have 512MB in my Ultra 2 and can't >> upgrade the memory - how am I supposed to install B70? >> >> > This was fixed in b72 and b70a. I believe b70a is available. 512MB does > work now for the text based installer. This was a temporary situation > due to the increase in miniroot size from the Gnome pkgs. This has been > fixed. > I am sorry, b70a isn't quite available yet. So, you will have to wait. It appears that this will be ready some time this week. sarah > Please try b70a and let me know if you have issues. > > Regards, > sarah > *** > >> William >> >> > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Should B72 be here any day now?
William Pursell wrote: > On 8/29/07, Dennis Clarke <[EMAIL PROTECTED]> wrote: > >>> I don't know if this is the proper forum to address this question, but >>> I am under the impression that B72 (the ksh93 project was integrated >>> in B72, right?) should be here any day now? >>> >> I'm still waiting on b70b >> > > What's the holdup? > Respins like this are for stopper bugs. As such, they get delayed occasionally. We are working on it. sarah > William > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXDE3
Iban Nieto wrote: > It's SXDE (with build 75) already to download ??? > SXDE 3, b70b, is available for download here: http://developers.sun.com/sxde Or, you can download a later build, b72 via Solaris Express Community Edition. Which has the SXDE bits included if you use DVD. http://opensolaris.org/os/downloads/on/ Regards, sarah > > > This message posted from opensolaris.org > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pciclass and login error
ofofhgij wrote: > ...I'm having issues with starting up the Live cd. > > first of all, when loading the Live Cd, the first thing(s) i see is an error > message that continues to appear throughout the entire loading session. > > WARNING: pciclass, 0607000: odd cardbus present state 0x > > WARNING: pciclass, 0607001: odd cardbus present state ox > > ...and it repeats, about every second or so. > > my next problem is truly stupidity, once solaris loads (it loads even with > those error messages) it asks me for a username and a password umm... > I tried just about anything I could think of to log in with no avail... is > there some username/password that I must know of to get in? > yes, jack/jack. sarah > any help, specially with the latter, is much appreciated. and again, sorry > for the noobness. > > > This message posted from opensolaris.org > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Indiana observations
Mario Goebbels wrote: >> with qemu -std-vga i got a little further. In fact, it'll boot all the way, >> but it is slw without kernel-kqemu. >> >> Installing to "hard disk" image and it goes to 86% (took a few hours to get >> there) but a few hours more and it is still there. I see devfsadm locked >> 100% (prstat -mL) >> >> Any suggestions? >> > > I haven't even let it go past 16% during the install phase, when I've > lost my patience. Not sure why kernel-kqemu breaks it, since it appears > to run fine in similar technology, i.e. VMware. > My suggestion is to file a bug at defect.opensolaris.org for the qemu/Indiana installer interaction issues. The classification/product/component I would file this under is: Development/installer/other As far as I know we haven't tried the installer under qemu. We need to figure out what's going wrong. As part of hte bug filing can you include the following data: /tmp/install_log /tmp/install_log.debug(if it exists) /tmp/gui-install_log /a/transfer.log thanks, sarah *** > -mg > > > > > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [advocacy-discuss] [indiana-discuss] I'm sorry, but I just don't get it
John Plocher wrote: > Shawn Walker wrote: > >>> Tell that to whoever violated ARC by putting /usr/gnu at the head of >>> $PATH in the indiana preview ;) >>> >> No violation of ARC occurred. ARC is not a required process until >> consolidations are integrated, etc. >> > > On the other extreme, it would be extremely stupid^H^H^H^H^H^H ineffective > to bundle up all the changes made to Indiana and produce them at the end > of February in one un-reviewablely large "we're done, here is everything > we did" ARC case > > There seems to be a bunch of stuff that got started, is being prototyped > and played with, has gotten integrated into a gate somewhere and was > shipped as part of a developer prototype release that still isn't on the > ARC radar. > I am not sure what you are referring to. We have not integrated anything in to any gate at this point in time, other than the various project gates which you see on opensolaris. And, one internal slim installer gate that will be open shortly(waiting on final legal I think). None of these are official gates, just prototype gates. This is simply a prototype, nothing integrated anywhere that requires ARC or PAC approval. We know what needs to be done process wise and certainly will follow all appropriate process along the way. Nothing in Feb is gonna be bundled up and put forth as a huge ARC case. > That's the point that has a bunch of us concerned - not that the review > hasn't been completed, but that they many of them haven't even been started! > > There simply wasn't time. And, since this is a prototype we felt that the way we did this was ok. In actuality though, some of Indiana has been ARC'd. The installer pieces were ARC'd as part of Dwarf Caiman(SXDE). Please don't invite trouble by assuming we won't do the right thing. There is a great group of engineers working on this project and we all believe in the benefits of review. Regards, sarah >-John > > > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [advocacy-discuss] [indiana-discuss] I'm sorry, but I just don't get it
>> hasn't been completed, but that they many of them haven't even been started! >> >> >> > There simply wasn't time. And, since this is a prototype we felt that > the way we did this was ok. In actuality though, some of Indiana has > been ARC'd. The installer pieces were ARC'd as part of Dwarf Caiman(SXDE). > Oh, a couple of other things went through review as well... lofi compression and hsfs performance changes. sarah > Please don't invite trouble by assuming we won't do the right thing. > There is a great group of engineers working on this project and we all > believe in the benefits of review. > > Regards, > sarah > >>-John >> >> >> ___ >> opensolaris-discuss mailing list >> opensolaris-discuss@opensolaris.org >> >> >> > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 'more' broken in b77 miniroot?
Can you file a bug? solaris/solaris_install/install_setup would be the classification for this. Regards, sarah [EMAIL PROTECTED] wrote: > >> Process 10 has it's stderr open on the console in O_WRONLY mode. >> And a "svcprop svc:/system/install-discovery:default" >> (or "svcprop install-discovery") reveals this start/exec property: >> >>/sbin/install-discovery < /dev/console > /dev/console 2>&1 >> >> >> > Looks like that needs to be fixed: > > /bin/install-discovery 0<>/dev/console 1>&0 2>&0 > > Casper > > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXDE 9/07 install "fails immediately"
Hi Mark, Sorry for the delay in responding..just catching up from the holiday break. It would be good to see the /tmp/gui-install_log and /tmp/install_log when this occurs. Obviously, this shouldn't happen. sarah Mark Drummond wrote: > I am trying to install SXDE 9/07 in a vmware 6.x vm. After stepping through > the installation GUI, when I click the last button to begin the install, the > GUI comes back immediately with an "installation failed" error message, > *but* the installer is actually still running in teh background. My disk and > the dvd drive are still spinning and you can see installf in the ps output. > > Anyone else seeing this? > > > > > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/sbin/format: where is the -force flag?
Hi Daniel,
I am the developer who did the work for this feature. We originally had
a force flag planned for all the utilities that were modified to enable
in use checking. However, the force flag was an area of much debate and
in the end we removed it. We recognize this is a potential issue for
experienced sysadmins. My suggestion, file an RFE and if enough people
feel this is an issue then we can revisit this decision.
And, yes you are correct, NOINUSE_CHECK does disable in use checking but
is not intended to be a public interface.
thanks,
sarah
*
Daniel Rock wrote:
Hi,
this week I gave snv_36 a try (hadn't upgraded for a long time) - and
this new "feature" (put in double quotes) was getting me in rage:
6194015 PSARC/2004/776 - Device in use checking for Solaris utilities
What I normally do after Solaris installation is mirroring the boot
disk via SVM. Sometimes I forget to reserve a small region on the disk
for the metadb. No problem - I then usually do the following steps:
1. disable swap (swap -d /dev/dsk/c0t0d0s1)
2. reduce swap by the required amounts of cylinders (usually metadb
doesn't
get more than 1 cylinder - hehe, I'm on the cheap side)
3. create a metadb with the freed up space
But this new feature also forces me to uncomment the swap entry in
/etc/vfstab (only to reactivate it later - two completely unnecessary
steps):
# format c0t4d0
selecting c0t4d0
[disk formatted]
Warning: Current Disk has mounted partitions.
/dev/dsk/c0t4d0s0 is currently mounted on /. Please see umount(1M).
/dev/dsk/c0t4d0s1 is normally mounted on according to /etc/vfstab.
Please remove this entry to use this device.
{ shrink slice 1 and create another slice }
partition> la
Cannot label disk when partitions are in use as described.
partition> aarrgh!&"/()%#
aarrgh!&"/()%# is not expected.
If you do this early after installation with /sbin/sh as your shell
and no job control you cannot even ^Z format and edit /etc/vfstab. You
have to quit format and start from the beginning.
This happens when programs try to be more clever than the
administrator - as a result they behave like Windows systems or HAL
("I'm sorry, Dave. I'm afraid I can't do that.")
By accident I also found a workaround today:
6291309 PSARC/2005/461 - libdiskmgt should enable bypassing of in-use
checking
Sounds good, but how is it done? Well not officially documented at all
but studying the source code I found out I just have to set the
environment variable "NOINUSE_CHECK".
But it should be a simple command line option in format, preferrable
the already existing -e (expert) option (-f is already in use).
Daniel
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/sbin/format: where is the -force flag?
One other thing... use utility/other for cat/subcat and please add me to
interest list, [EMAIL PROTECTED]
thanks,
sarah
Daniel Rock wrote:
Hi,
this week I gave snv_36 a try (hadn't upgraded for a long time) - and
this new "feature" (put in double quotes) was getting me in rage:
6194015 PSARC/2004/776 - Device in use checking for Solaris utilities
What I normally do after Solaris installation is mirroring the boot
disk via SVM. Sometimes I forget to reserve a small region on the disk
for the metadb. No problem - I then usually do the following steps:
1. disable swap (swap -d /dev/dsk/c0t0d0s1)
2. reduce swap by the required amounts of cylinders (usually metadb
doesn't
get more than 1 cylinder - hehe, I'm on the cheap side)
3. create a metadb with the freed up space
But this new feature also forces me to uncomment the swap entry in
/etc/vfstab (only to reactivate it later - two completely unnecessary
steps):
# format c0t4d0
selecting c0t4d0
[disk formatted]
Warning: Current Disk has mounted partitions.
/dev/dsk/c0t4d0s0 is currently mounted on /. Please see umount(1M).
/dev/dsk/c0t4d0s1 is normally mounted on according to /etc/vfstab.
Please remove this entry to use this device.
{ shrink slice 1 and create another slice }
partition> la
Cannot label disk when partitions are in use as described.
partition> aarrgh!&"/()%#
aarrgh!&"/()%# is not expected.
If you do this early after installation with /sbin/sh as your shell
and no job control you cannot even ^Z format and edit /etc/vfstab. You
have to quit format and start from the beginning.
This happens when programs try to be more clever than the
administrator - as a result they behave like Windows systems or HAL
("I'm sorry, Dave. I'm afraid I can't do that.")
By accident I also found a workaround today:
6291309 PSARC/2005/461 - libdiskmgt should enable bypassing of in-use
checking
Sounds good, but how is it done? Well not officially documented at all
but studying the source code I found out I just have to set the
environment variable "NOINUSE_CHECK".
But it should be a simple command line option in format, preferrable
the already existing -e (expert) option (-f is already in use).
Daniel
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/sbin/format: where is the -force flag?
Bill Sommerfeld wrote: On Fri, 2006-04-28 at 18:05, Sarah Jelinek wrote: partition> la Cannot label disk when partitions are in use as described. I do not think a -force flag is appropriate. instead, we should improve the granularity of the in-use detection -- fix format so it lets you change the sizes of partitions which are not in use so long as you aren't making them overlap in-use partitions. It does allow you to change the sizes of partitions which are not in use, as long as they don't overlap in use partitions. It even lets you grow in use partitions. The heuristic of the vfstab being 'in use' could be improved upon however, which I believe is Daniel's main concern. The idea is that entries in /etc/vfstab are possibly in use, and designed to help users not step on filesystems that may not be mounted at that time, but could potentially be something they want to keep. sarah - Bill ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Google Summer of Code: Call for OpenSolaris Participation
Hi Ricardo, Just as an FYI... there is an opensolaris project we just started, FUSE on Solaris, that you might be interested in watching. http://opensolaris.org/os/project/fuse/. Regards, sarah * Ricardo Correia wrote: Hi, I'm a computer engineering student from Portugal, and I would love to make a ZFS implementation for FUSE (Filesystem in Userspace) for Linux (and FreeBSD). I know it would be cool to have a kernel-level implementation, but that would be too big of a project for me work on my own. However, I'm fairly confident I would be able to do a mostly-complete implementation of ZFS on Fuse on my spare time. Is there a possibility to arrange a mentor for this project from ZFS/Opensolaris? Thank you. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Google Summer of Code: Call for OpenSolaris Participation
Joerg Schilling wrote: Sarah Jelinek <[EMAIL PROTECTED]> wrote: Hi Ricardo, Just as an FYI... there is an opensolaris project we just started, FUSE on Solaris, that you might be interested in watching. http://opensolaris.org/os/project/fuse/. How shpuld this deal with the incompatibilities of the Linux FS interface and the Solaris FS interface? Well... we are using the freeBSD port of FUSE as a starting point. freeBSD is similar to Solaris in that it uses vnode ops and vfs ops(although named slightly differently). Linux has structures for both file operations and inode operations, which Solaris and freeBSD combine as vnode ops. So, this will have to be dealt with, but we are starting from a more compatible source than the linux FUSE. What we need for OpenSolaris is a project that makes the native Solaris Fs interface available at user space. Certainly a possibility. Not in scope for this project though, at least for the initial port. thanks, sarah Jörg ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: /usr/sbin/format: where is the -force flag?
UNIX admin wrote: I am the developer who did the work for this feature. We originally had a force flag planned for all the utilities that were modified to enable in use checking. However, the force flag was an area of much debate and in the end we removed it. We recognize this is a potential issue for experienced sysadmins. My suggestion, file an RFE and if enough people feel this is an issue then we can revisit this decision. I definitely second enabling the admin to do what he needs to do. Simply bind the override functionality to -e, because that's the expert mode. That's certainly an interesting option on how to handle this. I hadn't thought of -e but that makes some sense for this type of functionality. And if I know about the expert mode, that implies that I know what I'm doing. So I want all and any obscure functionality available to me when I run `format -e`. No trying to be "smart", no "intelligence", just give us a "Voodoo-hoodoo what-you-don't-dare-do-people" functionality with -e. It is already noted in the man pages that the expert mode is to be used with caution and only if one knows what one is doing. Good point. sarah This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: /usr/sbin/format: where is the -force flag?
Jürgen Keil wrote: this new "feature" (put in double quotes) was getting me in rage: 6194015 PSARC/2004/776 - Device in use checking for Solaris utilities What I normally do after Solaris installation is mirroring the boot disk via SVM. Sometimes I forget to reserve a small region on the disk for the metadb. No problem - I then usually do the following steps: 1. disable swap (swap -d /dev/dsk/c0t0d0s1) 2. reduce swap by the required amounts of cylinders (usually metadb doesn't get more than 1 cylinder - hehe, I'm on the cheap side) . create a metadb with the freed up space But this new feature also forces me to uncomment the swap entry in /etc/vfstab (only to reactivate it later - two completely unnecessary steps): Yep. I also detected this "feature" when trying to write a crash dump for a live running kernel, with savecore -L: 1. swap -d /dev/dsk/c1d0s1 2. dumpadm -d /dev/dsk/c1d0s1 3. savecore -L 4. dumpadm -d swap 5. swap -a /dev/dsk/c1d0s1 dumpadm in step 2. now complains with: dumpadm: /dev/dsk/c1d0s1 is normally mounted on according to /etc/vfstab. Please remove this entry to use this device. I have to edit /etc/vfstab twice, before step 2. and after step 5. I will file a bug. Basically, the swap -d doesn't remove the swap entry from vfstab, and then we get in to trouble from there. 1 question, why do you have to remove the entry again after step 5? I filed a bug, 6420795 device in use checking should be more discrimating with /etc/vfstab entries to track this. In this case, the dumpadm -d should have been allowed. thanks, sarah This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: /usr/sbin/format: where is the -force flag?
Jürgen Keil wrote: I have to edit /etc/vfstab twice, before step 2. and after step 5. I will file a bug. Basically, the swap -d doesn't remove the swap entry from vfstab, and then we get in to trouble from there. 1 question, why do you have to remove the entry again after step 5? In step 5 I edit /etc/vfstab to *add* the swap slice which I had to remove in step 2. Otherwise this swap slice wouldn't be used the next time I reboot. Ah..ok, got it. thanks, sarah *** This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_51 doesn't offer upgrade from snv_49
[EMAIL PROTECTED] wrote: Hello opensolaris-discuss, I had to re-install to snv_51 on my x64 workstation. Installer didn't offer upgrade option - :((( System was put on mirrored SVM volume. Zones (zone upgrade not yet supported in Nevada, I think)? No, not yet. Due soon. Did you have local zones configured? sarah Checked the log file? Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_51 doesn't offer upgrade from snv_49
James C. McPherson wrote: Sarah Jelinek wrote: [EMAIL PROTECTED] wrote: Hello opensolaris-discuss, I had to re-install to snv_51 on my x64 workstation. Installer didn't offer upgrade option - :((( System was put on mirrored SVM volume. Zones (zone upgrade not yet supported in Nevada, I think)? No, not yet. Due soon. Did you have local zones configured? Does LiveUpgrade work though? No. If it doesn't, can I as a workaround for the moment do this: shutdown all zones backup /etc/zones to somewhere safe rm /etc/zones/* The zones have to be in sync with the system, so backing them up for a restore later won't work. All you you can do is uninstall the zones, do the upgrade, reinstall the zones, and do your customizations for the zones. Basically, there is no point in doing a backup of the zones. sarah * reboot with the new dvd choose the upgrade option Thanks in advance, James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_51 doesn't offer upgrade from snv_49
James C. McPherson wrote: Sarah Jelinek wrote: [EMAIL PROTECTED] wrote: Hello opensolaris-discuss, I had to re-install to snv_51 on my x64 workstation. Installer didn't offer upgrade option - :((( System was put on mirrored SVM volume. Zones (zone upgrade not yet supported in Nevada, I think)? No, not yet. Due soon. Did you have local zones configured? Does LiveUpgrade work though? If it doesn't, can I as a workaround for the moment do this: shutdown all zones backup /etc/zones to somewhere safe rm /etc/zones/* reboot with the new dvd choose the upgrade option One other piece of data.. the zones upgrade project is very close to putback. If you can hang tight until that integrates, another build maybe, then you can do your upgrades. sarah Thanks in advance, James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Project Proposal: Caiman, Solaris install revisted
Project Proposal: Caiman, Solaris Install Revisited I would like to propose the Caiman project for OpenSolaris. Caiman is the code name for the project to create a new Solaris installation experience. The current working ideas center on concepts such as: * Updated and simplified graphical and text user interfaces which carry Sun's current branding * Integrated hardware compatibility testing * Integrated live CD/DVD experience to provide the ability to use Solaris without committing your hard drive to an install. * Deep integration with the latest Solaris features, such as ZFS, Xen and SMF * Simplified system configuration, integrated with the post-installation experience * Simple, fast, and reliable installation of additional software after installation * Easy upgrades This project would live under the Installation and Packaging community. Initial Project Leaders: Dave Miner Sanjay Nadkarni Sarah Jelinek Frank Ludolph ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal : OpenSolaris on extended partitions
Pavan T C wrote: Hi, The aim of the project is to enable the installation and booting of OpenSolaris from an extended partition. This project will be delivered in multiple phases. The first phase is to introduce all OS changes necessary to support booting from and managing extended partitions on OpenSolaris. Here are the list of changes for phase 1 : 1. Driver Changes ( cmlb : modification) 2. Tools to perform partitioning (fdisk, format : modification) 3. Library to provide partitioning support (libfdisk : new) 4. Grub changes ( GRUB and installgrub : modification) The next phase involves changes to the installer. However, this is distribution specific and the changes might be independent of each other. One more possible change for the next phase involves creating device nodes for the extended partitions. Currently we do not create any nodes for the extended partitions. Pavan, I agree that the support for extended partitions in the utilities is critical. I am wondering how you propose to do the install support in OpenSolaris when the install consolidation is currently not open. And, the installation team is working on a new installer, Caiman, which would likely be the place this work would be done, depending on resolution of the open issues noted in this thread. So, the phasing including the installation pieces needs some clarification and coordination with the installation team. thanks, sarah The phase 1 changes have already been mostly completed. However, a detailed review and subsequent code changes are yet to be done. Looking for the community support to make the project move to completion. The PSARC materials and the existing code will be put up shortly. Thanks, Pavan Chandrahekar Sheshadri Vasudevan This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris installation problem
If you could send the log data, that might help. I assume the error is on first reboot? Can you provide more details? Such as installer used(I am assuming liveCD, x86), not AI. The install log, before first reboot is: /tmp/install_log thanks, sarah * On 02/ 8/10 01:36 PM, Manish Sharma wrote: I down loaded live open solaris 9.06 and installation error comes up saying [b]"Enter User name for system maintenance" (control-d to bypass):[/b] (See /lib/svc/share/README for more information.) Where do i find this Readme file. So I don’t know why I get this but I downloaded several iso image from open solaris website but same error result. i have set my hardrive as raid 0 1.5 tb. Any ideas where to look for solution to this problem? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SUNWluu packages for b132
They are not available in IPS. You can install the SVR4 packages on your system, but I am not sure what you need the live upgrade user package for. We don't use the old live upgrade on OpenSolaris, we have 'Snap Upgrade', which is managed via beadm(1M). Regards, sarah On 02/15/10 07:29 AM, Tom Buskey wrote: Where can I download them? They're not installed and I can't find them on the .iso ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SUNWluu packages for b132
On 02/15/10 07:53 AM, Florian Manschwetus wrote: Am 15.02.2010 15:38, schrieb Detlef Drewanz: SUNWluu is a Live Upgrade Package and existed for Solaris 10 and Nevada. This technology has changed within OpenSolaris. See beadm(1M) on how to create and update boot environments. Detlef Tom Buskey schrieb am 15.02.10 15:29: Where can I download them? They're not installed and I can't find them on the .iso ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org I would mention pkg image-update --be-name [how should your be named?] for just live upgrade, may be that is all what Tom needs? Yes, a pkg image-update is all he needs to do an upgrade on his system. But, beadm(1M) provides other capabilities he may be interested in. Regards, sarah Florian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Any one knows which package libzonecfg.h is in and how to find out?
On 04/ 2/10 09:13 AM, Henry Pepper wrote: Halton helped me with identifying the package as SUNWzoneint. I'm trying to build the 'gate' system, following - http://hub.opensolaris.org/bin/view/Project+indiana/constructor_notes - http://blogs.sun.com/sunwg11nprg/entry/how_to_create_opensolaris_distribution1 I'm trying to find a way to build OSOL distro so I can build an Amazon AMI. You can get it here: http://dlc.sun.com/osol/install/downloads/current/ sarah * Henry On Fri, Apr 2, 2010 at 3:01 PM, wrote: Hello Does anyone know which package libzonecfg.h is in and how to find out? I'm not able to find the file in sxce 127. Any ideas are welcome Part of the source, not distributed. Why do you need it? Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 76B Cannot find install software
Horvath wrote: > I have in9-32max (nf680i) The controller is called nforce 680i. I tried to > install b87 but I get " solaris express developer edition can only be > installed from dvd media..." > If I choose solaris express then I get "Cannot find Java software exiting to > shell." > > That means it can't find the java cpio archive we create to save memory in the miniroot. But, choosing SXDE means we shouldn't be looking for this archive, since we are using an x86 image. Did you try any of the other install options, such as the text console? thanks, sarah > > This message posted from opensolaris.org > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Open Solaris Community Edition NV93 Java Error
Hi Bill, This sounds like it cannot find the java archive it needs to unpack in to memory to enable the installer. Can you mount the image and send me the data about what is in it, specifically under Solaris_11/Tools/Boot, or /boot is fine. thanks, sarah *** Bill Nevis wrote: > Has anyone else seen an error when > > Installing Open Solaris x86 > 1. Solaris Interactive (default) and > 3. Solaris Interactive Text (Desktop > 4. Solaris Interactive (Console) modes > Menu options 1,3,4. > > Error: Cannot find Java software, Exiting to shell > > > This message posted from opensolaris.org > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Pre-Flag Day: AI schema changes in build 147
Hi All, If you don't use the Solaris Automated Installer(AI) you can safely ignore this message. Otherwise please read on...or read the pre-flag day message at: http://hub.opensolaris.org/bin/view/Project+caiman/Pre-Flag+Day+for+bug+16423 Starting in build 147 there will be changes in AI which will result in a flag day. Specifically the changes are: -AI schema and manifest changes -AI server:'installadm' cli changes in support of the new AI schema The changes to the AI schema and the resulting AI manifests are not backward compatible. If you wish to deploy Solaris Nevada build 147 or higher you must use the newer AI manifest. This means you must update your AI server to build 147 as well. The changes to 'installadm' will allow for backwards compatibility for managing builds earlier than b147. This backwards compatibility will be maintained until b157. ***AI schema and manifest changes*** The changes to the AI schema and the resulting AI manifest were made to provide a user interface that is more intuitive and easy to use. The new AI interface provides the same functionality as AI does today. The new interface will allow for expansion of AI functionality. The New AI manifest format for build 147 will provide the same functionality as is currently provided with AI. The AI schema changes are being made to allow for enhancement of AI functionality while trying to maintain compatibility moving forward. The AI schema has been changed to utilize DTD as the schema language and to add new element and attribute definitions. The AI manifest will no longer be an embedded manifest with the AI criteria manifest. The AI criteria manifest will be a separate entity. This is detailed below in the installadm(1m) changes section. Documents that will help you get started on making this transition are: New AI default.xml manifest: === http://hub.opensolaris.org/bin/download/Project+caiman/Flag+Days/default.xml New AI ai_manifest.xml manifest: === http://hub.opensolaris.org/bin/download/Project+caiman/Flag+Days/aimanifest.xml Use case transition guide: = http://hub.opensolaris.org/bin/download/Project+caiman/Flag+Days/usecases.txt XSLT file for manifest transformation from old->new: === http://hub.opensolaris.org/bin/download/Project+caiman/Flag+Days/old%2Dto%2Dnew.xslt To transform the old manifests using the XSLT document run the following command: xsltproc -o If /usr/bin/xsltproc is not available on your system, you can install it with: pfexec pkg install pkg:/library/libxslt Please verify the output from running this transform to ensure that everything is correct in the new manifest. Details: 1. are the top level tags for the new AI manifest. 2. Top level target specification for AI: These are the top level elements to specify a target for use in the root pool for installation. It is not required. If not specified, the AI client will choose the disk. The algorithm used for choosing the disk remains unchanged. Specifically the rules are: 1. The installer gets the recommended size for installing the OpenSolaris OS from the AI libraries. Currently, the recommended size is 13 GB. 2. The installer searches for available disks on the client. To determine the default target, the automated installer looks for an available disk with at least recommended size. The disks are found in the order they are reported by the libdiskmgt library. 3. When the first disk is found, the installer checks the size of that disk. -If the size is greater than or equal to the recommended size, the installer selects the disk and returns to the installation procedure. -If the size is less than the recommended size, the installer goes to the next disk to check the size. 4. If there is no match, the automated installation fails. A target_device can be one of the following types: disk, swap or dump device 3. At the top level a target disk must be specified using this path: target/target_device/disk 4. A disk can be specified by a name, a set of properties to describe the disk, a keyword or an iscsi device. A disk can also contain partitions and/or slices. 5. Disk criteria are divided into the following mutually exclusive groups: G1: Deterministic disk criteria === target/target_device/disk/iscsi parameters target/target_device/disk_name, with name_type attribute: one of ctd, volid, devpath or devid G2: non-deterministic disk criteria === target/target_device/disk/disk_prop: Any of dev_type, dev_vendor or dev_size G3: Keyword disk criteria = target/target_device/disk_keyword: boot_disk 6.
