Hi, The problem is caused, I think, by device numbering differences in xen versus ec2.
I solved this problem when creating my AMIs by the following procedure. 1. Create an extra volume in EC2 with the same size as the instance boot volume. 2. Attach the extra volume to the instance. 3. zpool attach the extra volume (c1t1d0?) zpool attach rpool c4t0d0 c1t1d0 4. zpool detach the original volume with incorrect name (c4t0d0) zpool detach rpool c4t0d0 5. zpool attach the original volume with the proper name (c1t0d0) zpool attach rpool c1t1d0 c0t0d0 6. zpool detach the extra volume. zpool detach rpool c1t1d0 7. Detach the extra volume from the instance and delete it. Double check all disk names in your instances first! regards Al On 20/07/18 01:46, PÁSZTOR György wrote: > Hi, > > I'm learning amazon, so I thought it would be nice, if I'd play with an > omnios inside my free tier experiments instead of linux. > I installed omnios from the "official" source: ami-0169c5108d1bdfd57 > (Yes, I choose Ohio instead of N. Virginia to play at) > > One small sidenote: ipv6 is not enabled in the official image, however I > configured so for the instance. After install I manually run this: > ipadm create-addr -T addrconf xnf0/v6 > Well, it solved everything. It seems way more simpleer then toying with > linux. > > But... I can not update my instance. > pkg update created the omnios-1 be, but I can not activate it. > root@ip-172-31-28-110:~# beadm list > BE Active Mountpoint Space Policy Created > omnios NR / 801M static 2018-05-04 18:52 > omnios-1 - /tmp/tmpTvggQP 158M static 2018-07-20 00:15 > root@ip-172-31-28-110:~# beadm activate -v omnios-1 > be_do_installboot: device c4t0d0 > be_do_installboot: install failed for device c4t0d0. > Command: "/usr/sbin/installboot -m -f /tmp/tmpTvggQP/boot/pmbr > /tmp/tmpTvggQP/boot/gptzfsboot /dev/rdsk/c4t0d0s0" > Errors: > open: No such file or directory > Unable to open device /dev/rdsk/c4t0d0s0 > be_run_cmd: command terminated with error status: 1 > Unable to activate omnios-1. > Error installing boot files. > root@ip-172-31-28-110:~# ls -l /dev/rdsk/*t0d0s0 > lrwxrwxrwx 1 root root 34 Jul 18 22:07 /dev/rdsk/c1t0d0s0 -> > ../../devices/xpvd/xdf@51712:a,raw > lrwxrwxrwx 1 root root 8 Jul 20 00:21 /dev/rdsk/c4t0d0s0 -> > c1t0d0s0 > root@ip-172-31-28-110:~# /usr/sbin/installboot -m -f /tmp/tmpTvggQP/boot/pmbr > /tmp/tmpTvggQP/boot/gptzfsboot /dev/rdsk/c1t0d0s0 > bootblock version installed on /dev/rdsk/c1t0d0s0 is more recent or identical > Use -F to override or install without the -u option > > root@ip-172-31-28-110:~# zpool status -v > pool: syspool > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > syspool ONLINE 0 0 0 > c4t0d0 ONLINE 0 0 0 > > errors: No known data errors > root@ip-172-31-28-110:~# echo | format > Searching for disks...done > > > AVAILABLE DISK SELECTIONS: > 0. c1t0d0 <Xen-Virtual disk-1.0-8.00GB> > /xpvd/xdf@51712 > Specify disk (enter its number): Specify disk (enter its number): > > > Well, I'm stucked at this point. I don't know how could I fix these. > I assume, the problem is, somewhere around the c4 vs c1 numbering, so it > try to open the wrong device. > > Note.: So let's just assume, it should work, without running the installboot > command. > > root@ip-172-31-28-110:~# cd /usr/sbin > root@ip-172-31-28-110:/usr/sbin# mv installboot installboot.save > root@ip-172-31-28-110:/usr/sbin# ln -s ../bin/true installboot > root@ip-172-31-28-110:/usr/sbin# beadm activate -v omnios-1 > be_do_installboot: device c4t0d0 > Command: "/usr/sbin/installboot -m -f /tmp/tmpTvggQP/boot/pmbr > /tmp/tmpTvggQP/boot/gptzfsboot /dev/rdsk/c4t0d0s0" > Activated successfully > root@ip-172-31-28-110:/usr/sbin# reboot > OmniOS 5.11 omnios-r151026-b6848f4455 June 2018 > root@ip-172-31-28-110:~# beadm list > BE Active Mountpoint Space Policy Created > omnios - - 3.66M static 2018-05-04 18:52 > omnios-1 NR / 1.01G static 2018-07-20 00:15 > > Will. It's a very dirty hack. Is there a nicer way to fix this c4 vs c1 > thing? > Btw.: it seems installboot would give back false, even if it could open the > device, because it already has the same version of boot block. Shouldn't > that circumstance checked on behalf of beadm? > > Cheers, > gyu > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
