We have a little situation that I was hoping I could get pointed in the right direction for (or maybe someone would offer some services that our company could pay for, etc).

We have a new Solaris 10 server - Sun Fire V240, that we needed for a fiber equipment NMS.
It came with 2 disks but only one disk is being used at present. We don't have a Solaris support contract other than the hardware warranty.
We need to setup software raid before the company that supports the fiber nms, will support it. We found the following DOC to help us:
http://www.tech-recipes.com/solaris_...n_tips225.html

Its a good procedure from what I can see but a little outdated. We are basically stuck at Step 1, which is verifying disk layout to determine if there slices available for meta logging. I can run df and look at the disk structure setup, but I'm not experienced to know what i'm looking for or how to create the slices I need.

Can anyone help?

the free partition that you need for the metadbs won't show up on df, you need to either verify it with prtvtoc or format, basically look for slices that have some free disk space and aren't being used for anything

chances are you didn't allocate this space during the installation, and you don't have free space on the disk, so i suggest you remove a small space from swap (32-64mb) and allocate it to slice 7 (usually that is where metadbs are placed)

if you do have free space on the partition table, just allocate 32mb to another slice using format

if you don't have free space use swap -l to list your swap, remove your current swap using swap -d, re-partition the swap space and allocate 32mb to a slice that isn't being used (usually slice 7)

Why dont you use ZFS raid instead? Much much easier to handle, and safer.

i don't think its possible yet to set the root filesystem as ZFS, unless this was changed recently with the new release of solaris 10.

You are correct. ZFS root/boot support is still experimental and available only with Solaris Express on x86 H/W.

http://opensolaris.org/os/community/zfs/boot/

Nothing prevents you to use ZFS on non root slices on your disks though.

I have a separate 250GB system disc on UFS and a separate ZFS raid pool with 4 samsung 500GB discs. It works good. All data is saved on the pool. If I reinstall Solaris, the pool wont get affected, as I only have to format the system disc. I would prefer it this way.

If I had installed the Solaris system on the ZFS pool, then I couldnt easily reinstall Solaris, as the whole pool would be affected. I prefer to have data separate from solaris.

I don't get your concerns about reinstalling. Pools and filesystems are distincts entities. You would be able to install on a new ZFS filesystem on the same pool without touching the existing ones. Moreover, you would also be able to upgrade your current system, and instantly rollback provided you create a snapshot before the upgrade.

I imagine even having a multiple boot configuration based on different clones of the same original installation.

ZFS opens absolutely amazing new ways of thinking in term of administration.

Ok, Im a Solaris noob switcher, and come from the Windows world. When using Windows, the file system gets "polluted" and you soon want to reinstall Windows to get a clean install. You mean that, that is not needed with Solaris? But, doesnt the file system gets polluted, with lots of programs installed everywhere and librarys and so on?


Another question; if I install a program, sometimes it turns out that the program was unnecessary (found a new version, another similar program, etc). How do I uninstall in a clean way? I imagine the installed programs puts files everywhere and alters the PATH and so on. How do a sysadmin normally uninstall programs? Read the install script and manually undoes every change? Tracks which files get altered during an install?

Say that you install fontforge v2 and later you install fontforge v3. Will the v3 files overwrite the v2 files? But what if all files in v2 doesnt get overwritten, because changed file structure? Will the unused v2 files just lie there, and potentially be a source of future problems? Shouldnt I delete those unused files? Hence, the file system gets polluted and soon I would want to do a complete reinstall? Or, is there a way of first uninstall v2 completely (by means of a program or doing it manually) then install v3, the file system wont get polluted?

Many questions, but I hope you can give som pointers so I can learn more.

An application installed under Windows is supposed to bundle a working uninstaller.
The reality is both the implementation and the uninstallers are weak and indeed you soon reach to the point a reinstall is the most reasonable issue.
Not to mention the pieces of software, viruses and other malware that intentionally break this design.
Usually no, especially as there isn't a "registry base", or at least what is used instead is much more robust, and of course like other Unix/Unix-like, viruses aren't targetting Solaris.
If you install packaged programs, you can uninstall them with no issue.
pkgrm <package-name>
The location of the files that form a package is well know by the O/S.
PATH isn't something that is changed by the installation of a new package. It is up to the users or adminstrators to update global PATH if needed.
I already answered for software installed as packages. There are other ways to install new software, like compiling from source. In that situation, the developer should have include a process to both install and uninstall the programs. The O/S has no clue about these files, but there is no overlapping between the these two modes. The directories used are distincts.
Either v2 and v3 install in different directories and that's OK or they don't and you'll be asked to uninstall v2 first.

Finally, what I describe is the ideal situation but in the reality the risk the system become partially or totally broken because of a human mistake or wrongdoing, a bug, a broken patch or a hardware failure is not null. This is where ZFS is really helpful as it allows you to easily revert to a previous working state or just to compare the current an one of the previous stored states (snapshots).