Monday May 05, 2008
As of a little while ago, the official bits for OpenSolaris 2008.05 went live, at the distro's home site, opensolaris.com.
While it may seem odd to say, I view this day more as a beginning than
an ending (though I am more than happy to call an end to the 60+ hour
weeks that went into building it!). It's a beginning in many ways, but
I'll just say that while we've shipped an image and loaded up a pretty
good number of packages into the repository, most of the functionality
we plan to ultimately have isn't there yet, not to mention the number
of packages we want to have in the repository.
At the moment I'm
too worn out from the weekend at the OpenSolaris Summit to even attempt
to write anything technical, as it likely wouldn't make any sense, so
I'll just keep this short and close with a big THANK YOU to everyone on
the Caiman team for all the work they've done in getting us to this
milestone. It's time to feel good about what we've done.
Look forward to seeing lots of you at CommunityOne!
Friday Apr 25, 2008
A test image for the 2008.05 release from Project Indiana is now available, see Stephen's announcement. We'd appreciate any feedback!
Wednesday Feb 13, 2008
The second preview of Indiana was pushed out for download about 15 hours ago as I write this. As those who are following closely know, we'd actually made a testing image available via Bittorrent a couple of weeks ago in order to broaden the testing exposure. This time the image actually got some professional and community testing, as opposed to Preview 1, which basically had about 1 hour of some of us trying to boot it on every machine we could get our hands on. Thanks to those who took the time to test it!
The announcement has the general highlights and links off to all of the bugs we've fixed. From an installation point of view, the changes in this preview are mostly under the hood. The most notable ones include:
- Most visibly, at least to those who encountered it, we fixed the bug that prevented you from using 'v' in the passwords of the root user and the user created during installation.
- A better PATH and MANPATH for the user account created at installation.
- The ZFS dataset hierarchy has been renamed and reorganized a little, it is now similar to what will be used in the ZFS boot/install project that'll be added to Nevada and Solaris 10. For the preview, you'll now see the root dataset named
rpool/ROOT/preview2. In the same vein, we now take a snapshot of all of the datasets at installation (snapshot name is @install) so that it's easy to tell what's been changed, and to get back to the start state of the system should that be needed for some reason. /boot/grub/menu.lst now points you off to the "real" menu, which is at /rpool/boot/grub/menu.lst.- The introduction of
pkg verify pointed out some errors in the installation code, primarily around zero-length files, which we've fixed. A verification after installation will show some issues with modes of Python compiled files, but otherwise it'll be quite clean.
I've been running this on my laptop and desktop for a week now, and I've had no issues. If you're feeling adventurous, a couple of things I've done on my laptop.
First, I'm running with a compressed root. The installer doesn't support this right now, but you can easily fire up a terminal window and, once the installer's created the data sets, do a zfs set compression=on rpool/ROOT/preview2 and all of the installed software will be in compressed data sets. You need to do this quickly in order to get as much compressed as possible, since anything copied onto the data sets before the compression is enabled will not be compressed. After adding OpenOffice and a lot of other packages, I'm at 1.94 GB for the root dataset, with compression ratios reported at 1.8x or so.
The second thing is running Preview 2 as an xVM dom0. Three steps for this:
pkg install SUNWvirtinst SUNWurlgrabber SUNWlibvirt SUNWxvmhvm SUNWxvmdom SUNWxvm- Manually edit
/rpool/boot/grub/menu.lst and add the xVM entry. The normal method for doing this is bootadm -m upgrade, but it doesn't work for Indiana because of the menu being moved for ZFS root. The entry should look like title OpenSolaris xVM
kernel$ /boot/$ISADIR/xen.gz
module$ /platform/i86xpv/kernel/$ISADIR/unix
/platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive
- Run the following commands to update the sysevent registrations so that you can install domU's (fixing this is bug 509):
pfexec syseventadm add -c EC_xendev /usr/lib/xen/scripts/xpvd-event \
'action=$subclass' 'domain=$domain' 'vdev=$vdev' \
'device=$device' 'devclass=$devclass' 'febe=$fob'
pfexec syseventadm add -c EC_xpvsys /usr/lib/xen/scripts/xpvsys-event \
'subclass=$subclass' 'shutdown=$shutdown'
If you do give Indiana a spin, please report any bugs you find at
defect.opensolaris.org.
Friday Jan 11, 2008
In one of our meetings the other day I was pointing out to the team that I could tell most of them weren't using Indiana as their primary development platform, because I was finding bugs in the Caiman source release when attempting to build it using Indiana. Usually we're pretty good at eating our own dog food, but that hasn't really happened much yet with Indiana, in part because we've had a couple of other things to do at the same time. Some of the team suggested that one of the issues holding them back is that there's a bunch of additional stuff you need to add to the base Indiana install to make it suitable for development use, and they didn't feel they had the time to figure it out. Well, fortunately, I already have, at least for Caiman development, since I put Indiana on my laptop right after we released it 2.5 months ago, and my desktop a few weeks later (my desktop at home is still running SXCE for a bunch of mostly lame reasons). So, without further ado, here's my brief cheat-sheet on how to get an Indiana system into shape for OpenSolaris development:
- Follow the instructions for downloading the live CD, burning it, booting it, installing from it
- Once you've booted from the disk, make sure you update the system (which is mentioned in the above instructions, but bears repeating since it will fix some critical problems, such as the broken SVR4 packaging software on the preview media).
- Install the header files:
pkg install SUNWhea - Install Mercurial:
pkg install SUNWmercurial - Install make:
pkg install SUNWsprot - Install Java:
pkg install SUNWj6rt - Follow the instructions to download and install the compilers and build tools, though you'll want the tools from the SCM Migration project so that they work with Mercurial.
- In order to build the Caiman sources, download and pkgadd SUNWwbint, SUNWzoneint, and SUNWldskint (SUNWldskint isn't up there yet, we're working on getting that corrected).
- If you have an NVIDIA graphics controller, then you probably want to install NVDAgraphics and NVDAgraphicsr from the Nevada media or NVIDIA's web site.
- A few other things you might find yourself wanting; first two are on the Nevada media.
- SUNWflash-player-plugin
- SUNWrealplayer
- OpenOffice 2.3
I haven't tried building the OS/Net sources on Indiana since I haven't had a need lately, but I don't know of any reason why it wouldn't work.
Thursday Nov 15, 2007
I'm happy to report that we've just released more installation source code to OpenSolaris. What we've released today is the source code which corresponds to the Dwarf Caiman installer which appeared in SXDE 9/07, and the Slim Install installer that's used in the OpenSolaris Developer Preview. It also encompasses the SVR4 packaging code which had been released previously, but which is now being made available via the Mercurial repository rather than the tarball releases we'd been doing.
This is a significant milestone, as it represents essentially all of the source base that we're using in building the new installer in the Caiman project and finally opens us up for meaningful contributions from the community. Thanks to Moriah for her hard work on this, as well as the others on the team who helped with research and reviews!
Friday Nov 02, 2007
I've posted my slides from my talk about /demo of the preview release at last night's NEOSUG meeting, get 'em in PDF or ODP format. Thanks to those who came by, hope you had good luck with the CD's we handed out!
Thursday Nov 01, 2007
One of the things we developed between BeleniX and the Live Media project is the ability to run the live CD bits on USB flash drives, and indeed, that's what I mostly demo, because it's a lot faster (boot time is under a minute, install time for the OpenSolaris Developer Preview is about 7 minutes) - Jonathan loved it when we demo'ed it a couple of weeks ago. We don't push USB images yet because right now you need to already have Solaris installed in order to copy it to the USB stick. But if you do have Solaris Nevada (or have installed the preview!) already, and a copy of the preview ISO, you can make a USB flash drive for yourself, as follows:
- Use mercurial to get a copy of the Distribution Constructor repository:
hg clone ssh://anon@hg.opensolaris.org/hg/caiman/distro_constructor
Go into the distro_constructor/tools directory and run usbgen, this will take roughly 10 minutes:
./usbgen <path_to_iso_file> <path_to_usb_image> `pwd` <tmpdir>
- Plug your USB flash drive into the system, give the system a few seconds to see it, then run usbcopy, this will usually take 3-5 minutes, depending on your flash device; usbcopy will discover all your removable media and let you pick the right device:
./usbcopy <path_to_usb_image>
You'll need a 1 GB or larger USB flash device, since the image is 600+ MB.
Thursday Nov 01, 2007
One the indiana-discuss and caiman-discuss lists a poster wrote:
> /bin/sh -c 'print ${.sh.version}'
> /bin/sh: bad substitution
>
> I hoped Indiana would improve things and deliver the ksh 93 as
> /bin/sh, but no, it is just the same bourne shell as in Solaris. No
> improvement. Indiana doesn't improve things for developers.
>
> The choice for /bin/bash as user shell for 'Jack' and 'root' is a SHAME.
As I think this is representative of a broader set of issues in OpenSolaris, I decided to post this as a blog entry rather than just email to the lists. Let me explain how this "choice" came to be...
When the OpenSolaris project opened a couple of years ago, Moinak Ghosh and friends built a distro called BeleniX, a very nice piece of work which I respect even more after what we've gone through in building this preview. One of the things they developed was the tools for building a live CD, and in that kit they'd made a number of choices, which included that bash was the shell for root. Sensible, since ksh93 wasn't ported at that time.
A bit later, I started collaborating with Moinak on bringing the live CD technology to the Solaris base, in the OpenSolaris Live Media project. We worked in the background on it for a year or so, tweaking it and updating it for later Nevada builds as I worked on the political end of getting Solaris management to buy into this as our future approach. I was doing this project in my spare time, as was Moinak, and we didn't really have any other particularly active contributors other than Anil Gulecha (who did the original USB work) and a couple of patches I got from others. For our purposes, bash was fine, it worked, and I didn't need to bother changing it, so I didn't.
When Ian came along and got Sun management to buy into doing Indiana with a preview in October and including the new installer, live CD, new packaging system, we were already working in that direction, but by the time we got staffing freed up from other things, we had about 10 weeks to get to this preview release. You don't do that by making lots of random changes and creating lots of new code (IPS is an exception to the latter) so we used what we had, cobbling things together, and that meant we borrowed from Live Media to create the Distribution Constructor, which used bash. And in the last 4 weeks of 14 hour days, this wasn't a priority to change, so it didn't.
The moral of the story above is that if you get involved and contribute code to projects, you *will* make decisions in that code which will show up in distributions; Live Media would have welcomed contributions along the way. We need coders, not managers, as Sun pays plenty enough of them already. If you're going to pass final judgment on this distro based on this preview, then that's unfortunate; we've done some good work, I think, but we've also cut a *lot* of corners to get to where we are, by focusing on the things we knew we had to do and leaving the other things for later. That won't be quite so necessary going along, but my years of delivering projects tells me we're going to postpone something from every milestone, and make someone unhappy every single time, so I'm disappointed by the tone of some of these comments, but not surprised. The code for much of this is out there now, between the Distribution Constructor and IPS repositories, and now is the time to start offering patches. We'll welcome them.
Wednesday Oct 31, 2007
Well, we went a little later today than planned, but the preview release of Project Indiana is out in the wild. It's too late in my US/Eastern timezone to write much right now, but I'll just say before I go to bed that I'm glad to have reached this milestone. And those of you in the Boston area can come to the NEOSUG meeting Thursday night where I definitely will say more, and show what we've done so far. And if you're really up for jumping in, help you install it!
Friday Oct 05, 2007
Peter's posted the announcement of the next New England OpenSolaris User Group.
Fourth NEOSUG Meeting « Peter Baer Galvin’s Blog
Should be an interesting juxtaposition of how we're both continuing to provide Solaris compatibility with the Solaris 8 Migration Assistant and at the same time exploring new territory with Project Indiana. I'd write more, but I need to get back to getting that Indiana preview ready so I'll actually have something to talk about ;-) Hope to see you there!
Friday Sep 14, 2007
Jumpstart usage with non-Sun DHCP servers is a question that comes up fairly often. A good posting I noticed today on the sunmanagers mailing list:
Solaris JumpStart vs the Microsoft DHCP Server - Larry Rosenman's personal blog
(reposted to update link to Larry's blog)
Monday Aug 20, 2007
Over the weekend, Solaris Nevada build 70 was pushed out to the Sun Download Center. This build is the first candidate for the next Solaris Express Developer Edition (SXDE) release, which means the work of the Dwarf Caiman team is now generally available. Due to a number of bugs that have already been found in internal testing we know there'll be at least one "re-spin" build, 70a, before we'll call it the SXDE release. In the meantime, please try it out and let us know how it works via caiman-discuss (or on our new IRC channel, #caiman-discuss at chat.freenode.net). While you're downloading, read on for a couple of comments I'd like to make in relation to this new installer.
Probably the most important thing to understand is that we're closer to the beginning of producing a truly new installer here than the end. This project was specifically scoped to provide a new graphical interface for SXDE as soon as possible, replacing the tired old GUI that's been in place for several Solaris releases now and which we'd done some minor tweaking of late last year when the SXDE program started. To allow for delivery in the time frame we've done this on (the project went from zero to delivery in 6 months), we specifically didn't change the underlying install engine, a moldy old warhorse known as pfinstall. The code to discover and identify the available storage (what we call "target discovery" in the architecture) is mostly new, and there's a new thing called the "orchestrator" which provides the interfaces the GUI uses. But the actual installation and upgrade process still relies on pfinstall, which is driven by a Jumpstart profile generated by the GUI/orchestrator combo. Replacing the rest of pfinstall is the subject of current and future projects within the Installation and Packaging community.
Because we were specifically scoping this project for SXDE, we could make a couple of simplifying assumptions - the old installer is still there for all the things we don't choose to support yet. For those of you who are experienced Solaris users, the one you may notice is that there's no way for you to set up the UFS slices within the Solaris FDISK partition. That was intentional, and it's because you're an experienced Solaris hand that this is even particularly noticeable; however, if that's true, then you're not the target audience for this iteration of the installer. The target users here are people new to Solaris, and the concept that you have to both set up an FDISK partition plus lay out slices within that partition is confusing to every single one of them. So we just left it out for now, in favor of a canned layout for fresh installs that is more appropriate than the one the old installer uses (read the discussion thread on this for details); its most important attributes are that the root slice will be larger than before, and if the FDISK partition specified is sufficiently large, you'll get a second, alternate root for use with Live Upgrade by default. Later projects will be adding more control over the file systems than is provided here, but even before that we're expecting we'll move to ZFS as the root file system. The pooled storage model of ZFS is specifically meant to eliminate slicing as a common exercise for system administration, so I'm not expecting it to be a particularly commonly-used function in the finished installer, either.
You might also notice that we've added configuration of an initial user account, rather than just setting the root password and leaving you to your own devices to figure out how to create a user. Again, this is a simplified interface - you don't get to choose uid's or groups, just the necessary basics, which is essentially identical the to Gnome Users & Groups tool's basic settings tab. If you're part of a NFS environment where uid's and gid's matter, then by all means adjust these once you're installed, and if the administrative tools don't do what you need, please file bugs. The philosophy here is to configure a few basics necessary to get started, but not require you to get everything exactly right to start with, so if there's something in the tools that makes that not work, we'll get it fixed.
The last thing I'll mention at this point isn't new, but was new in the SXDE 5/07 release and thus may not be particularly familiar yet. The installer doesn't ask you to do any network configuration, because it enables Network Auto-Magic instead. If you find that NWAM's a little too magical (or perhaps not magical enough yet, since it's still an early version, too) for your taste, you can switch to the standard Solaris networking configuration with sys-unconfig, which will force a reboot and walk you through the standard old configuration dialogs.
Thursday Aug 09, 2007
For those of you in the Northeast US, the traveling developer conference that we call Sun Tech Days
will be coming to Boston next month, September 11-12. I'll be speaking at the OpenSolaris Day on the 11th, covering the "What is Solaris Nevada?" session, which will include an update on Indiana. These sessions are free, but you do need to register to attend. Hope to see you there!
Tuesday Jul 31, 2007
Just a note that the project meetings for the rest of the new OpenSolaris installer project are finally starting, and are open to anyone interested:
New OpenSolaris Installer Weekly Meeting at OpenSolaris.org
We're days away from integrating the Dwarf Caiman project, which provides the initial implementation of the new GUI for the next Solaris Express Developer Edition release, shortly after which we should be releasing much more source code. At that point we'll be about as open as open can be.
Friday Jul 20, 2007
I've been in the New York City area this week, taking part in presentations to the local customer base on a variety of Solaris topics; in my case, focused on Solaris 10 patching. Wednesday evening turned out to be a bit more intense than I bargained for, as Spencer, Brian Wong and I were having an impromptu discussion with a customer after the day's event had concluded when there was a fairly loud bang, followed by a sustained, roaring rumble. At first it sounded like the thunder we'd had earlier in the day, but when it continued for more than 30 seconds, we looked out the window, and realized people were running away from our building. Taking that as a cue, we hurriedly shook hands and headed for the emergency exits. Turned out to be the steam pipe eruption (though we didn't know that for roughly an hour), which was only a couple hundred yards from Sun's NYC office on Park Ave. That chaotic scene also turned out to be the context for my first introduction to Ian and Sara Dornsife as we scrambled down 41st St. Hopefully this isn't a harbinger for our collaboration on Indiana! It was a relief to hear that the cause of all that chaos was a failure of some aging infrastructure rather than an intentional act, but that will do little to ease the pain of those injured in the accident. My deepest condolences to them; those of us who were in the area and got out unscathed really have to feel lucky. My thanks to Ambreesh for his aid in getting to our hotel in NJ that night, as well as Isaac for retrieving my stranded bags from Park Ave. Thursday morning.
In Solaris, we've got our share of aging infrastructure as well, very notably in packaging and patching. Its failures haven't been as dramatic as that steam pipe, but it's been failing nonetheless and becoming ever harder to maintain as the demands on it have increased. We've been doing our best to band-aid the patching situation for Solaris 10, the latest being the addition of Deferred Activation Patching, which provides a mechanism to safely apply complex changes to the system in contexts where Live Upgrade can't be used (I still recommend Live Upgrade as the preferred alternative). Even as we've been patching patching, though, we've well understood that a fundamental reconstruction of our packaging system is in order to solve the core issues and have been exploring approaches to that task. I'm delighted that Stephen has posted his initial observations on the topic, and I'd encourage everyone to give it a read and join the conversation. There will be much more to come in the next few weeks as this turns into a full-blown project on OpenSolaris.
|
|
|
|
I just downloaded it and so far it looks pretty gr...
hi,
I have download and installed Opensolaris 05/0...
hi,
I just downloaded and installed...
@Marco: You should be able to find mplayer package...
Thanks you! for mplayer.
I installed Opensolaris...