Update EON from snv_125

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.