Open Stack

Hi George, thank you for helping. Now, it is working. Bellow the answers
for the questions.
I do not know what happened to fix the problem. I uploaded a new image in
the VMDK format. So, that image worked. When I tried to boot the qcow2
again, it got work again. Very strange. Makes no sense.

When you sent the first message about the size of the disk, I changed all
sizes in all images but they did not work. Now, all images have a numeric
minimum disk size. I'm guessing that there were some cache of information
in compute nodes and after some time (or operation, the upload of the new
image with different format) the size value was uploaded. This makes more
sense.

--

Yes. I got the image here
http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img

file xenial-server-cloudimg-amd64-disk1.img
xenial-server-cloudimg-amd64-disk1.img: QEMU QCOW Image (v2), 2361393152
bytes

So, I uploaded using Dashboard interface.

# glance image-list
+--------------------------------------+---------------------------------+
| ID                                   | Name                            |
+--------------------------------------+---------------------------------+
| 4042dc9e-3c18-44cf-94c8-83a0cd3f2b34 | CentOS 7                        |
| f6f686a0-1b20-4145-b994-ba5099c5db7f | Cirros                          |
| 38505fbf-931b-4abb-a597-b2d5bddbce14 | Fedora 25                       |
| 440759bb-4fdf-4f00-80af-beb96603503c | openSUSE 13.2                   |
| 3337bc25-c176-4055-b163-27fbd5fd6b41 | Ubuntu Server 16.04 LTS         |
*| dea4fcc9-ee19-4b9b-a144-2e203af998bb | Ubuntu Server 16.04 LTS QCOW    |*
| d83837d2-ce64-4391-b96e-d5ed9d2fdb2c | Windows Server 2012 R2 Std Eval |
+--------------------------------------+---------------------------------+

# glance image-show *dea4fcc9-ee19-4b9b-a144-2e203af998bb*
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| architecture     | x86_64                               |
| checksum         | ea7e3472f778730063b0c483e00abe4f     |
| container_format | bare                                 |
| created_at       | 2017-01-20T16:31:37Z                 |
| description      | Ubuntu Server 16.04 LTS QCOW         |
| disk_format      | qcow2                                |
| id               | dea4fcc9-ee19-4b9b-a144-2e203af998bb |
| min_disk         | 5                                    |
| min_ram          | 2048                                 |
| name             | Ubuntu Server 16.04 LTS QCOW         |
| owner            | 769822d4bf984cfeb3ab910cec9fa5b3     |
| protected        | False                                |
| size             | 322502656                            |
| status           | active                               |
| tags             | []                                   |
| updated_at       | 2017-01-20T16:31:38Z                 |
| virtual_size     | None                                 |
| visibility       | public                               |
+------------------+--------------------------------------+

That image wasn't working. When I uploaded the VMDK one, them this QCOW
started work again.

Anyway thanks for the help.

But I still do not understand what caused the problem.

Cheers!



- JLC

On Fri, Jan 20, 2017 at 2:21 PM, George Mihaiescu <lmihaiescu at gmail.com>
wrote:

> Did you upload the .img version of the cloud image?
>
> Can show the output of the "glance image-show xxx"?
>
> On Jan 20, 2017, at 11:05, Jorge Luiz Correa <correajl at gmail.com> wrote:
>
> Yes, I've tried with 0 (without define a minimum size) and with large
> sizes. Same error.
>
> Two things that I've noted:
>
> 1) When I create a volume based on the image, I can boot the system
> normally. But, when I try to launch the instance as ephemeral disk (without
> volume on storage), I get the error.
>
> 2) When I use 'file' to compare the backing file on compute nodes (the
> image that compute nodes download from glance on controller, in
> /var/lib/nova/instances/_base) I see different information between the
> Cirros image (that works) and Ubuntu (that fails).
>
> file Cirros -> DOS/MBR boot sector; GRand Unified Bootloader, stage1
> version 0x3, stage2 address 0x2000, stage2 segment 0x200
>
> file Ubuntu -> DOS/MBR boot sector
>
> Could this be the problem?
>
> - JLC
>
> On Fri, Jan 20, 2017 at 11:47 AM, George Mihaiescu <lmihaiescu at gmail.com>
> wrote:
>
>> Check if the flavour you chose has a large enough root disk.
>>
>> On Jan 20, 2017, at 08:25, Jorge Luiz Correa <correajl at gmail.com> wrote:
>>
>> Hi, I need some help with images that I can't boot. I've here some images
>> like Cirros, Ubuntu, Fedora, CentOS etc. All downloaded as indicated here:
>>
>> http://docs.openstack.org/image-guide/obtain-images.html
>>
>> Some weeks ago they were working fine. But now, I can boot only Cirros
>> image. Ubuntu, Fedora, CentOS etc give me the same error, as bellow
>> (example of Ubuntu).
>>
>> ------------------------
>>
>> Begin: Running /scripts/init-premount ... done.
>> Begin: Mounting root file system ... Begin: Running /scripts/local-top
>> ... done.
>> Begin: Running /scripts/local-premount ... [    4.703377] Btrfs loaded
>> Scanning for Btrfs filesystems
>> done.
>> Begin: Waiting for root file system ... Begin: Running
>> /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> Begin: Running /scripts/local-block ... done.
>> done.
>> Gave up waiting for root device.  Common problems:
>>  - Boot args (cat /proc/cmdline)
>>    - Check rootdelay= (did the system wait long enough?)
>>    - Check root= (did the system wait for the right device?)
>>  - Missing modules (cat /proc/modules; ls /dev)
>> ALERT!  LABEL=cloudimg-rootfs does not exist.  Dropping to a shell!
>>
>>
>> BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
>> Enter 'help' for a list of built-in commands.
>>
>> (initramfs) [  722.260923] random: nonblocking pool is initialized
>>
>> ------------------------
>>
>> Tests already done:
>>
>> - download all images again and update on glance;
>> - delete files in instance/_base diretory of compute nodes forcing them
>> download new images from controller;
>> - look for errors on logs (no errors, images are spawned normally);
>>
>> Tks!
>>
>> - JLC
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170120/0f22179a/attachment.html>