According to andre, best is to fresh install. Failing that:
I have a working windows -> USB install but not yet ready for release. USB install/image coming ...
For now what you can do is
Insert 2nd key(new) and run install.sh. Install to new key.
After it is done you will have a clone of the first key.
Then, use transporter with the new iso to overwrite the 2nd key that you just installed/cloned.
Now you have the new image installed on the new key.
so, let's try that.
First, list all the drives:
media:5:~#echo | format -e
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0
/pci@0,0/pci8086,3a46@1c,3/pci1458,b000@0/disk@0,0
...
9. c3t4d0
/pci@0,0/pci1458,b005@1f,2/disk@4,0
then plug in the USB key and try again:
media:6:~#echo | format -e
Searching for disks...
The current rpm value 0 is invalid, adjusting it to 3600
done
c4t0d0: configured with capacity of 14.80GB
AVAILABLE DISK SELECTIONS:
0. c0t0d0
/pci@0,0/pci8086,3a46@1c,3/pci1458,b000@0/disk@0,0
10. c4t0d0
/pci@0,0/pci1458,5006@1a,7/storage@5/disk@0,0
Specify disk (enter its number): Specify disk (enter its number):
I can clearly see that the 16GB USB key is c4t0d0
media:7:~#install.sh
This process installs EON ZFS Storage to a destination listed below:
[1] c0t0d0 (Unknown MB)
[2] c0t1d0 (Unknown MB)
[3] c1d0 (3816MB)
[4] c2t2d0 (Unknown MB)
[5] c2t3d0 (Unknown MB)
[6] c3t0d0 (Unknown MB)
[7] c3t1d0 (Unknown MB)
[8] c3t2d0 (Unknown MB)
[9] c3t3d0 (Unknown MB)
[10] c3t4d0 (Unknown MB)
[11] c4t0d0 (Unknown MB)
Enter destination choice[?]: 11
... lots of stuff, have to answer 'y' a few times
/mnt/install/boot/x86.eon: OK
EON ZFS Storage install complete on /dev/dsk/c4t0d0s0
rebooting... as before, my system hangs when a bootable solaris system is present on USB. It doesn't even finish listing all the PCI cards. So have to try again, targeting a second CF card.
media:4:~#install.sh
This process installs EON ZFS Storage to a destination listed below:
[1] c0t0d0 (Unknown MB)
[2] c0t1d0 (Unknown MB)
[3] c1d0 (3816MB)
[4] c1d1 (Unknown MB)
[5] c2t2d0 (Unknown MB)
[6] c2t3d0 (Unknown MB)
[7] c3t0d0 (Unknown MB)
[8] c3t1d0 (Unknown MB)
[9] c3t2d0 (Unknown MB)
[10] c3t3d0 (Unknown MB)
[11] c3t4d0 (Unknown MB)
Enter destination choice[?]: 4
After it succeeds, I shut down, remove the old boot system from slot 0 of the CF card, and move the newly created one from slot 1 to slot 0. It boots okay, I am able to log in with my previously created account, and verify that the pool is healthy and ip addresses are correct. Looks like the new install worked. Now I have a playground to update, and the safety of the old system on the other CF card.
Now it is time to upgrade to the latest and greatest. For versions of EON slightly newer than mine, the upgrade tool is/was transporter.sh - see
this post - and elsewhere in comments Andre advises those of us using older versions without transporter.sh to simply download the script from the downloads page.
I download transporter.sh and scp it into /tmp/ on my eon box.
Download the latest CIFS ISO and scp it into /tmp/ as well
Then as root on my eon box:
#chmod +x /tmp/transporter.sh
#/tmp/transporter.sh -i /tmp/eon-1.0b-151-64-cifs-min.iso -d /mnt/eon0
OK: lofiadm -a /tmp/eon-1.0b-151-64-cifs-min.iso /dev/lofi/1
OK: mount -F hsfs /dev/lofi/1 /tmp/upgrade
removing /mnt/eon0/boot
copying /tmp/upgrade -> /mnt/eon0
...
unmounting /dev/lofi/1
OK: umount /dev/lofi/1
releasing /dev/lofi/1
OK: lofiadm -d /dev/lofi/1
Great, complete with no problems. But we're not done quite yet. The new system just installed contains none of the setup I made to the original system - ip addresses, accounts, and other config. Normally we run updimg.sh to write changes we've made to the running system into the stored image so that they persist across a reboot. But in the comments
here Andre cautions that by default, that script will overwrite parts of the new system with the old one. So according to his advice, edit /mnt/eon0/.backup and comment out the three entries in /usr/bin/ to avoid reverting them. Then
#updimg.sh /mnt/eon0/boot/x86.eon
Updating files in /mnt/eon0/.backup to x86.eon
backup in /mnt/eon0/boot/x86.eon.1
/mnt/eon0/.backup: OK
gzcat /mnt/eon0/boot/x86.eon > /tmp/x86.1336
lofiadm -a /tmp/x86.1336 /dev/lofi/1
mounting ... /dev/lofi/1 /mnt/upd
copying /etc/svc/repository.db
umounting ... /mnt/upd
lofiadm -d /dev/lofi/1
mv -f /mnt/eon0/boot/x86.eon /mnt/eon0/boot/x86.eon.oem
gzip -f -9 -c /tmp/x86.1336 > /mnt/eon0/boot/x86.eon
/mnt/eon0/boot/x86.eon: OK
At this point we should be ready to reboot and enjoy our new system!
Rebooting, GRUB displays the new EON logo as well as the version number 0.97
Before the login prompt there are some errors related to the crypto service
I am not able to SSH in. I can log in using one of the accounts I previously created. zpool shows no pool. ifconfig -a shows that the ip address settings were also lost.
Unfortunate. I still have the disk with the original system, so I could go through the whole process again, but it is probably easier to move forward and fix the config.
first,
#zpool import
resurrects my pool. Everything looks healthy, although "zpool status" notes that I am using an older version of on-disk format (meaning that there is now a new version available but I have yet to upgrade).
Actually, the docs on the eonstorage google site don't mention such pedestrian configs as network addresses. Referring to the notes from my original install... I also glossed over those bits.
ifconfig fails with an "Object not found" error
svcs -xv shows:
svc:/network/physical:default (physical network interfaces)
State: maintenance since (time of boot)
Reason: Start method exited with $SMF_EXIT_ERR_CONFIG.
Impact: 21 dependent services are not running:
nfs
smb
etc
svc:/network/physical:nwam (physical network interface autoconfiguration)
State: disabled since (time of boot)
Reason: Disabled by an administrator
Impact: 21 dependent services are running
svc:/system/idmap/default (Native Identity Mapping Service)
State: maintenance since (time of boot)
Reason: Start method failed repeatedly, last exited with status 1
Impact: 5 dependent services
smb
nfs
etc
svc:/system/cryptosvc:default (cryptographic services)
State: maintenance since (time of boot)
Reason: restarting too quickly
Impact: 2 dependent services
ssh
milestone
Okay, that's a bit of a mess, but it seems that if I could get the network working the rest might fall into place. ifconfig -a does show both of my cards, so they seem to be working at the hardware and driver level. What is the recommended way to configure stuff in EON?
Well, /etc/hostname.rge0 does contain the IP address that I had previously configured. Looking at /usr/bin/setup, I try to reproduce it... all the relevant files seem to have the correct info from previous setup. The only missing step is to start the net service:
#/lib/svc/method/net-physical
/lib/svc/method/net-physical[73]: /sbin/ibd_upgrade: not found [No such file or directory]
ifconfig: cannot plumb rge0: Interface already exists
ifconfig: cannot plumb rge1: Interface already exists
configuring IPv4 interfaces: ifconfig: could not create address:Object not found
rge0ifconfig: could not create address:Object not found
rge1
Failed to configure IPv4 interface(s): rge0 rge1
it is true that /sbin/ibd_upgrade does not exist. Googling only turns up two results for "/sbin/ibd_upgrade: not found" neither of which offers a clear explanation
Reboot again and transcribe onscreen errors:
WARNING: No major number for driver mega_sas in class scsi
WARNING: failed to resolve 'scsa.probe' driver alias, defaulting to 'nulldriver'
WARNING: no randomness provider enabled for /dev/random. Use cryptoadm(1M) to enable a provider
Configuring devices
Failed to configure IPv4 interface(s): rge0 rge1
svc.startd[8]: svc:/network/physical:default: Method "/lib/svc/method/net-physical" failed with exit status 96.
svc.startd[8]: network/physical:default misconfigured: transitioned to maintenance (see svcs -xv for details)
... may have missed some, output too fast for video recording to keep up with
svc.startd[8]: svc:/system/idmap:default: Method "/usr/lib/idmapd" failed with exit status 1
... cryposvc
... failed to abandon contract 37: Permission denied
Okay, put that aside for now and continue with setup: edit /mnt/eon0/.exec and enter correct pool name.
zpool import -> success
updimg.sh /mnt/eon0/boot/x86.eon
init 6 -> reboot
my zpool is still not imported on boot, even though .exec contains my correct pool name. "zpool import" in the command line succeeds. It seems that .exec is not being run? Or it is run, but "zpool import -f -a" fails because SMB etc services can't be started.
So 2 main issues: networking fails, zpool doesn't load on boot. Need to seek help, and read through blog comments for any similar troubleshooting.
Andre suggests I just start over, so backup my upgraded img and copy the OEM one to /mnt/eon0/boot/x86.eon
So now I'm following the "new setups" instructions from
here
cd /mnt/eon0/bin
./slinky r
./slinky c
setup
check poolname in .exec
add group and user for media per my notes from original setup
updimg.sh
skip the nfs setup (I don't think I ever actually used it)
skip the permissions/owner/acl stuff for zfs and zpool - should be set correctly on disk from before, and I made sure to use same group and user IDs
reboot - zpool is online with no errors
okay i lied, I use NFS from my media server. Try to follow the instructions in
the faq but the paths don't work anymore. Perhaps they moved, or perhaps they're part of binary kit now?
Found the answer in the forums:
"
With the move to Illumos /var/svc/manifest/*.xml changed to /lib/svc/manifest/*.xml
Please redo the steps with /lib/svc/manifest"
Repeat the steps in under /lib/ and all the imports succeed, but:
#svcadm enable -r nfs/server
svcadm: svc:/milestone/network depends on svc:/network/physical, which has multiple instances.
nevertheless, despite the warning I am able to connect via NFS
For now, this seems to be complete and successful.