New imgadm has trouble doing initial upgrade if zones were created from a UUID that has no manifest

[nshalman]

How I encountered this:
My home system previously ran an older version of the platform.
I had created a blank KVM VM, and kickstarted fedora18 onto it.
I then took a snapshot of the disk zvol, cloned that snapshot to a new zones/$(uuid)
and used the resulting zvol UUID to create some additional VMs.

Upon rebooting the machine onto joyent_20130222T000747Z, imgadm is sad:

[root@smartos ~]# imgadm list

assert.js:102
  throw new assert.AssertionError({
        ^
AssertionError: "zones/e09ca63c-7d8f-4afe-a8e4-72b46f26f18d-disk0" image name is an origin for a zfs fs, but that image fs is not found
    at Object.keys.forEach.module.exports.(anonymous function) [as ok] (/usr/img/node_modules/assert-plus/assert.js:193:35)
    at IMGADM._loadImages.imagesInfo (/usr/img/lib/imgadm.js:917:24)
    at Array.forEach (native)
    at IMGADM._loadImages (/usr/img/lib/imgadm.js:916:45)
    at ChildProcess.exithandler (child_process.js:538:7)
    at ChildProcess.EventEmitter.emit (events.js:99:17)
    at maybeClose (child_process.js:638:16)
    at Process._handle.onexit (child_process.js:680:5)

For reference, some zfs output showing relationships

[root@smartos ~]# zfs list -t all -r zones/e09ca63c-7d8f-4afe-a8e4-72b46f26f18d-disk0
NAME                                                                 USED  AVAIL  REFER  MOUNTPOINT
zones/e09ca63c-7d8f-4afe-a8e4-72b46f26f18d-disk0                    9.50G   105G  8.93G  -
zones/e09ca63c-7d8f-4afe-a8e4-72b46f26f18d-disk0@fedora18installed   578M      -  1.07G  -

[root@smartos ~]# zfs get clones zones/e09ca63c-7d8f-4afe-a8e4-72b46f26f18d-disk0@fedora18installed
NAME                                                                PROPERTY  VALUE                                       SOURCE
zones/e09ca63c-7d8f-4afe-a8e4-72b46f26f18d-disk0@fedora18installed  clones    zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8  -

[root@smartos ~]# zfs list -t all -r  zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8
NAME                                                                                    USED  AVAIL  REFER  MOUNTPOINT
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8                                                1K   105G  1.07G  -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@04c5bc4b-bdb2-4df6-a89c-d2a39ac3f751-disk0      0      -  1.07G  -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@2de71ccc-d036-44b5-9c48-e83ad7ba1b46-disk0      0      -  1.07G  -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@2d21e9a4-5585-4fd4-8490-48e3940eb686-disk0      0      -  1.07G  -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@2631baa6-3345-46bc-ba1b-827ad7f3fe2e-disk0      0      -  1.07G  -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@f6ba0a50-1648-4c20-90d5-5e501fb334fc-disk0      0      -  1.07G  -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@6fec6382-c0d8-4200-bcad-77634621ac04-disk0      0      -  1.07G  -

[root@smartos ~]# zfs get clones | grep 22da38f0-5cfd-11e2-8345-ab9b0474aed8
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8                                             clones    -                                                 -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@04c5bc4b-bdb2-4df6-a89c-d2a39ac3f751-disk0  clones                                                      -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@2de71ccc-d036-44b5-9c48-e83ad7ba1b46-disk0  clones                                                      -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@2d21e9a4-5585-4fd4-8490-48e3940eb686-disk0  clones                                                      -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@2631baa6-3345-46bc-ba1b-827ad7f3fe2e-disk0  clones                                                      -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@f6ba0a50-1648-4c20-90d5-5e501fb334fc-disk0  clones    zones/f6ba0a50-1648-4c20-90d5-5e501fb334fc-disk0  -
zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8@6fec6382-c0d8-4200-bcad-77634621ac04-disk0  clones    zones/6fec6382-c0d8-4200-bcad-77634621ac04-disk0  -
zones/e09ca63c-7d8f-4afe-a8e4-72b46f26f18d-disk0@fedora18installed                     clones    zones/22da38f0-5cfd-11e2-8345-ab9b0474aed8        -

Since these VMs aren't critical, I can probably do a workaround of destroying them so that imgadm will be happy and then recreate them from scratch, but I'll hold off for a while in case I can do some useful diagnostics or testing.

[nshalman]

I'm not the only person hitting this:
http://www.listbox.com/member/archive/184463/2013/03/entry/19:27/20130303160911:9670A4A0-8446-11E2-9873-E4150E938EF9/

I'd also like to go back to using my machine, so a request for more information or a go-ahead to clean up my machine the inelegant way would be greatly appreciated.

Thanks!

[trentm]

@nshalman sorry for the delay. I'm looking at this now.

[trentm]

@nshalman I think this commit should fix this. You should be able to try it out quickly per the "dev-install" notes here: https://github.com/joyent/smartos-live/blob/master/src/img/README.md#development

I'd appreciate a note if that fixes it for you. Thanks, and sorry for the delay.

[nshalman]

I followed the instructions for doing a "dev-install" and things seem much better:

[root@smartos /opt]# imgadm --version
imgadm 2.0.2
[root@smartos /opt]# imgadm update
Upgraded image 01b2c898-945f-11e1-a523-af1afbe22822 data
Upgraded image 1c27c1a4-542d-11e2-991f-cbaf8fd7b428 data
Upgraded image 75559714-6bd0-11e2-aa72-fb522708e25d data
Upgraded image 7973148e-5c3a-11e2-b2e6-03d185ab694e data
Upgraded image 8700b668-0da4-11e2-bde4-17221283a2f4 data
Upgraded image c7622518-5b36-11e2-bcca-2fdaa594b790 data
Upgraded image c91b3752-79c5-11e2-ad33-67667b9ee2c2 data
Upgraded image ee1fb198-5fe1-11e2-9cce-e319fd47df7b data
Upgraded image f0c511e0-6c75-11e2-8cde-aff76d3c915c data
Upgraded image fdea06b0-3f24-11e2-ac50-0b645575ce9d data
Upgrade: imported image source "https://datasets.joyent.com/datasets"
Upgrade: imported image source "http://datasets.shalman.org/datasets"
Could not find image e1d0bc40-719b-11e2-8922-af0ade6b75ac in image sources

Other imgadm commands seem much happier now.

It also looks like there is a persistent warning about a different image source that I created "properly" (via zfs send and receive of a zvol from another machine) but without metadata:

[root@smartos /opt]# imgadm update
Could not find image e1d0bc40-719b-11e2-8922-af0ade6b75ac in image sources

But that message doesn't break proper functionality and could be considered a feature (it's a "you created an image without metadata, fool" warning).

Thanks for the fix!!