After digging into my memory banks, I think I got that kernel as an attempt
to come past that "bad kernel" gate of import-image, but that still didn't
work. Rather I needed to use import-snapshot, which doesn't seem to have
that gate. But it might require a raw image; I never tried anything else.

I don't remember where I got that kernel maybe a debian (?) or possibly I
compiled myself, but probably not. I obviously forgot it had non-standard
kernel. But as I remeber it now, the key was really to use import-snapshot
and not import-image. Perhaps it takes a vmdk. Otherwise you'll need to
convert to raw.

On Thu., 18 Apr. 2019, 02:52 Alexey Zilber <alexeyzilber@??? wrote:

> That's really helpful Ralph. Some of that stuff was still in
> /root/.bash_history btw on the vm, no worries though, not that much stuff
> leaked.
> I see that you use a raw image and do a snapshot import, that differs a
> bit from what I was doing (I was following what Packer does with
> amazon-import).
>
> Any hints on what you did with the kernel? Did you roll your own?
>
> -Alex
>
> On Wed, Apr 17, 2019 at 10:36 PM Ralph Ronnquist <
> ralph.ronnquist@???> wrote:
>
>> Right, it was some months ago; started on a write up at
>> https://git.devuan.org/ralph.ronnquist/upload-automation/blob/master/notes.md
>> as I aimed for automated building... Never completed 🙁
>>
>> Ralph
>>
>> On Wed., 17 Apr. 2019, 16:13 Alexey Zilber <alexeyzilber@??? wrote:
>>
>>> Thanks for the info about the Devuan ami in Sydney. Not sure if
>>> cloud-init would be the issue because it's an import problem, not a
>>> spinning up problem. I've seen people build AMI's without cloud-init and
>>> things have worked. Regardless, I used a variant of the
>>> https://github.com/cloux/aws-devuan repo cloud.cfg, they have a very
>>> "non-standard" build of Devuan on us-east-1 using runit, so I wanted to
>>> build something as close as possible to the base Devuan Ascii distro.
>>> Looking at "Devuan 2.0 ASCII (rrq)", I can see it differs somewhat from
>>> the base distro as well. Namely the kernel is upgraded, seemingly via
>>> backports, but not ascii-backports:
>>>
>>> *Linux ip-172-31-11-154 4.18.0-0.bpo.1-cloud-amd64 #1 SMP Debian
>>> 4.18.6-1~bpo9+1 (2018-09-13) x86_64 GNU/Linux*
>>>
>>> I don't know where this kernel image came from. Kernel 4.18 isn't in any
>>> Devuan or Debian backports.
>>>
>>> So I installed the signed kernel from ascii-backports and have the same
>>> issue:
>>>
>>> "StatusMessage": "ClientError: Unsupported kernel version
>>> 4.19.0-0.bpo.4-cloud-amd64"
>>>
>>>
>>>
>>> So I'm stumped. I grabbed the kernel .config from the ec2 instance and
>>> am trying to build my own kernel. But I don't have much faith left in it
>>> working....
>>>
>>> -Alex
>>>
>>>
>>> On Wed, Apr 17, 2019 at 2:00 AM Ralph Ronnquist <
>>> ralph.ronnquist@???> wrote:
>>>
>>>> Yes, I have on public in Ireland, same in Sydney. Possibly the key was
>>>> the fixed-up cloud-init package that CenturionDan made. As I'm travelling
>>>> until next week I can't look up details. But you could try it out, named
>>>> "Devuan 2.0 ASCII (rrq)".
>>>>
>>>> Ralph.
>>>>
>>>> _______________________________________________
>>>> devuan-dev internal mailing list
>>>> devuan-dev@???
>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>>>>
>>> _______________________________________________
>>> devuan-dev internal mailing list
>>> devuan-dev@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>>>
>> _______________________________________________
>> devuan-dev internal mailing list
>> devuan-dev@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>>
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>