live usb gets to grub but doesn't boot
After what seemed to be a near effortless upgrade from b134a to b148 OpenIndiana, I had upgraded the nvidia driver to NVIDIA-Solaris-x86-260.19.29 to get over the AGP bug (see https://defect.opensolaris.org/bz/show_bug.cgi?id=17441) and doing a zpool/zfs upgrade I happily destroyed b134.
Things were dandy and seemingly stable when I decided to upgrade from v3.3 rc5 to rc8 OpenOffice.
My mistake was [at least] twofold: I didn't create a snapshot or new boot environment, AND I didn't uninstall OOO rc5. so I ran strait into the wall by doing an pfexec ./update
after seeing with horror some error messages that went off the screen (and past the scroll back buffer)
my system was hosed. Thank you Oracle for the kindness accorded ...
Upon rebooting I got the following on the console:
svccfg: Loaded 172 smf(5) service descriptions
/etc/svc system profiles not found: upgrade system profiles
Preserving generic_limited hash (e1e4bd5ba67926c3ded2c112a26bffcb64a64a5533f275d3e19f8f256b683c8a).
and I could only get into maintenance mode.
Luckily I still had the solex_151a boot environment so I could try to determine what happened.
After a white night I was able to determine that the update fiddled (at least) with /bin, turning it into a normal directory instead of a symlink to /usr/bin. So I was able to get indiana back by moving the /bin directory out of the way and adding the symlink back to /usr/bin. for anybody interested, I have a zfs diff file, but since this is highly reproducible it shouldn't be necessarry.
I am concerned about what else might have been hosed so I'll ask now:
? Is it safe to do a 'pkg verify' and a 'pkg fix' to put things back in order?
Now to justify the subjet line, since initially in maintenance mode I couldn't really run pkg commands successfully (needing the network), I wanted to boot the OpenIndiana b148 live usb that I created.
Naturally, solex_151a barfs on pkg commands where openindiana.org is needed (and I don't yet dare to add openindiana as a publisher on solex for the moment since 151a is greater than openindianas 148).
The stick boots just fine into the grub menu, but when I select OpenIndiana (or VESA) nothing happens.
If I remove the stick I see a read error but otherwise nothing really interesting.
Is there any special incantation to get this stick to boot? For info, if I use it on a x64 machine, it does boot, but is realllly long.
Updated by Richard PALO over 11 years ago
Well, since I noticed that most operations started dumping core (even /usr/bin/ls), I prepared to abandon the fight..
But luck would have it after trying a couple of times more, I finally booted into the liveUSB after 3 or 4 minutes (which seems exceedingly long). So the bug should say "takes a very long time to boot" rather than "doesn't boot".
Initially this didn't help any at all because my shuttle needs the nfo driver for a network!
So I ripped out a compaq NC3131 from another system which indeed gave me 2 NICS (Equivalent to Intel 82557/8/9/0/1 Ethernet Pro 100 using the iprb driver. So at least I could proceed.
I started a dterm and su - root and devined the root password.
zpool import -f -R /a rpool beadm mount oi-148 /mnt cp -R /a/mnt/var/pkg/ssl /var/pkg -- to get my certificates for the extra repository pkg -R /a/mnt fix
and took a nap
pkg fix didn't like my localhost repositories (need to figure out how to point them to disk now with the updated pkg manager) but it seemed to go to work on the rest...
rebooted back into my "fix'd" boot environment and reconfigured the network to use the NC3131.
Now I'm holding my breath... would be nice to know how to "force" and image-update to get things savvy with some certainty...
in any event, I would add an RFE that any pkg install or uninstall should automatically do a snapshot ... if memory serves right, even M$ WinXP does so. Being able to add a commentary would help identify the purpose of each snapshot as well.
For non pkg manager installs/uninstalls, don't even consider doing so without creating a new boot environment. a reboot is cheap compared to a white night/day trying to scratch a system back in order.