I'm using "System" -> "Update Manager" to attempt a live update of my system. Started w/ OSOL11.08 and have updated 3 times successfully, but am now stuck at snv105 and all attempts to upgrade since will not boot into graphics console login state.
Since I use this system as a full time working desktop, I only have rare occasions to try new updates. Have been stuck at snv105 for about 6 weeks or more. The usual procedure is to kill everything (all my apps) but the basic OSOL desktop and invoke live upgrade before the end of the night. In the morning it is done (actually less than 10 or 15 minutes, and all seems well during the upgrade itself). When its complete and I go to reboot, the system hangs and tells me it cannot find solaris.xpm - after some sleuthing, it appears that in releases of OSOL up to and including update 3 after OSOL11.08, the file solaris.xpm (instead of solaris.xpm.gz) lives in /boot. Grub expects this file to be there as part of the console graphics based startup, as part of the three lines in menu.lst indicating the path to the file and the setting of foreground and background colors. If I try to delete these lines from the boot sequence in a live grub instance, it hangs on boot. If I boot from a previously known working instance of OSOL11.08 (i.e. system update manager update 3), I can edit the menu.lst file, remove the three lines, and the updated OSOL image will boot to snv109 in text mode. If I also put of a decompressed copy of solaris.xpm.gz in /boot, the system will attempt to boot in graphics-console mode, but then sits there and strobes endlessly on the "happy face boot" OpenSolaris splash image screen. No matter what I've tried so far, I cannot get any updated manager generated boot env's after the 3rd update following OSOL11.08 (anything after snv105) to boot into a windowed configuration. I have had problems with recent releases of the NVIDIA drivers for my particular config (Ultra 24 w/ FX1500 and FX5600), and have found the only release that works well is NVIDIA-Solaris-x86-100.14.19.run - which is relatively ancient. Back rev'ing the snv_109 image to these drivers has not helped. Anyone have a clue as to why I'm seeing these kinds of problems and why a system update manager generated boot env to snv109 (and everything update since snv105) fails? thx, barton fiske -- This message posted from opensolaris.org
