Just a few days ago I got my hands on a new motherboard to migrate the
system to; Gigabyte GA-990FXA-UD7 rev 1.1. It turned out that the
motherboard refused to post whenever a memory module is inserted in slot
DDR3_3. I thought at first that this was a hardware defect but after
flashing the BIOS to the latest firmware (F8a) and doing a "Load
Optimized Defaults" the issue was resolved.
In the process, the boot drive died on me (it doesn't even spin up) so
it seems that I won't be able to migrate the OI installation to the new
motherboard :( I noticed that if I fiddle with the power connection it
will power up occasionally, perhaps I could get the system to dump the
configuration files to migrate to a new installation. I have a backup of
the VirtualBox Image files on my storage pool but I'm not sure if I have
the xml's. We'll see if it is possible to rebuld the xmls. In the
meanwhile I have ordered an RE4 drive to replace the old Samsung HD103SJ
(which is under warranty tho).
Robin.
On 2011-09-11 14:41, Robin Axelsson wrote:
That was an interesting link. I wonder if these steps really are
necessary. It sure doesn't hurt to make a backup copy of
/etc/path_to_inst but creating an empty "reconfigure" file at the root
seems to be enough.
To describe the instructions in the "bug-report" in words:
(preparatory steps)
1. Boot using OSOL/OI LiveCD
2. Locate and mount the rpool of the system (zpool import -f rpool)
3. Locate and mount all the other pools as well (zpool import -f
<otherpools> - found using zpool list)
4. Locate and mount the boot environment into a suitable subdir under
root (beadm list; beadm mount opensolaris-n /subdir)
5. Move the path_to_inst and create a new empty one (mv
/subdir/etc/path_to_inst <another path>; touch /subdir/etc/path_to_inst)
(the actual modification procedure)
6. Clean and rebuild the device tree (devfsadm -C -r /subdir)
7. Clean and rebuild the device tree for disks only (devfsadm -c disk
-r /subdir) - is this really necessary??? Isn't that done in step 6
already?
8. Copy the actual zfs cache to the rpool (cp /etc/zfs/zpool.cache
/subdir/etc/zfs/zpool.cache)
9. Force a reconfiguration upon next boot (touch /subdir/reconfigure)
- pretty much as suggested by Tim Bell on this mailing list
10. Recreate the boot-archive (bootadm update-archive -R /subdir)
11: Run cd /; sync; sync; sync; - what's this for, and why run "sync"
THREE times?
12. VERY IMPORTANT STEP!!: Unmount the "opensolaris-n" boot
environment using the beadm command (beadm unmount opensolaris-n)
(reboot)
13. Reboot using e.g. init 6 and on next boot select in LiveCD grub
menu "boot from hard drive" - Wouldn't it be easier to just remove the
LiveCD before reboot?
I'm not sure why all these steps would be necessary as they should be
taken care of automatically when forcing a "reconfigure" in first
place. Thanks for your post!
Robin.
On 2011-09-10 19:50, Apostolos Syropoulos wrote:
Please have a look at
http://comments.gmane.org/gmane.os.solaris.solarisx86/35322
I had the same problem and the process described in
https://defect.opensolaris.org/bz/show_bug.cgi?id=5785
solved my problem.
A.S.
----------------------
Apostolos Syropoulos
Xanthi, Greece
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
