Error creating snf-image for Ubuntu Server 18.04

[Dani García]

Hi,

I'm trying to generate the snf-image for Ubuntu Sever 18.04 because isn't in the list of images listed in https://www.synnefo.org/docs/snf-image/latest/usage.html#sample-images. I'm using the image http://cdimage.ubuntu.com/ubuntu/releases/18.04/release/ubuntu-18.04-server-amd64.iso and following the steps of https://www.synnefo.org/docs/snf-image-creator/latest/usage.html#creating-a-new-image.

I have installed the most basic Ubuntu configuration with two partitios as suggested: one primary for root (/) and one primary for swap. Then, with snf-image-creator, I apply the default steps in "Expert" -> "Customize" -> "Sysprep" and the las step, called "Shrink" deletes de swap partition and save enough information to recreate it, as described on https://www.synnefo.org/docs/snf-image-creator/latest/usage.html#image-partition-schemes-and-shrinking.

Everything is ok, no errors, but when I copy the image to all my Ganeti nodes (/var/lib/snf-image/) and try to create a new instance, I get the following error:

# gnt-instance add -t plain -o snf-image+default -O img_format=diskdump,img_id=ubuntu18.diskdump,img_properties='{"EXCLUDE_TASK_ConfigureNetwork":"yes"\,"OSFAMILY":"linux"\,"ROOT_PARTITION":"1"\,"USERS":"root"\,"SWAP":"2:1024"}' --disk=0:size=6G --no-name-check --no-ip-check  -H kvm:vnc_bind_address=0.0.0.0,kernel_path="" -B memory=1G,vcpus=1 --net 0:link=br-lan --no-wait-for-sync ubuntu18

Mon Jul  2 17:36:27 2018 * disk 0, size 6.0G
Mon Jul  2 17:36:27 2018 * creating instance disks...
Mon Jul  2 17:36:29 2018 adding instance testub18 to cluster config
Mon Jul  2 17:36:29 2018 adding disks to cluster config
Mon Jul  2 17:36:29 2018 * running the instance OS create scripts...
Failure: command execution error:
Could not add os for instance testub18 on node node1.zoconet.es: OS create script failed (exited with exit code 1), last lines in the log file:
[MONITOR] {"subtype": "task-start", "task": "FixPartitionTable", "type": "image-helper", "timestamp": 1530545811.853033}
[MONITOR] {"subtype": "task-end", "task": "FixPartitionTable", "type": "image-helper", "timestamp": 1530545812.372859}
HELPER: 2018:07:02-15:36:51.876028528 run-parts: executing /usr/lib/snf-image-helper/tasks/20FilesystemResizeUnmounted
[MONITOR] {"subtype": "task-start", "task": "FilesystemResizeUnmounted", "type": "image-helper", "timestamp": 1530545812.411796}
HELPER: 2018:07:02-15:36:51.975698543 resize2fs 1.42.12 (29-Aug-2014)
HELPER: 2018:07:02-15:36:51.979399004 Couldn't find valid filesystem superblock.
HELPER: 2018:07:02-15:36:51.981825425 /sbin/resize2fs: Filesystem has unsupported read-only feature(s) while trying to open /dev/vdb1
[MONITOR] {"subtype": "error", "type": "image-helper", "stderr": "resize2fs 1.42.12 (29-Aug-2014)\n/sbin/resize2fs: Filesystem has unsupported read-only feature(s) while trying to open /dev/vdb1\r\n", "timestamp": 1530545812.49461}
HELPER: 2018:07:02-15:36:51.995649973 run-parts: /usr/lib/snf-image-helper/tasks/20FilesystemResizeUnmounted exited with return code 1
HELPER: sysrq: SysRq : Power Off
HELPER: reboot: Power down
2018:07:02-15:36:53.604862907 VM STOP
[INFO] Customization VM exited normally.
[MONITOR] {"messages": ["Customization VM exited normally."], "type": "image-info", "timestamp": 1530545813.641424}
[INFO] Checking customization status...
[MONITOR] {"messages": ["Checking customization status..."], "type": "image-info", "timestamp": 1530545813.697373}
[INFO] Customization status is:
[MONITOR] {"messages": ["Customization status is:"], "type": "image-info", "timestamp": 1530545813.733752}
[ERROR] Image customization failed.
[MONITOR] {"messages": ["Image customization failed."], "type": "image-error", "timestamp": 1530545813.770243}

If I avoid the "Shrink" step, which left the partitions untouched, it creates the VM, but I also have a problem because the partition that grows is the swap one, and it also creates a new swap partition:

/dev/vda1 *   2048  ... ...  2.6G  83 Linux
/dev/vda2     ...      ... ...  2.4G  82 Linux swap / Solaris  # The one that grows
/dev/vda3     ...      ... ...  1G    82 Linux swap / Solaris

I don't understand why in the first case it tries to read /dev/vdb1 when it doesn't exists. My Ganeti version, running in Ubuntu 16.04, is:

# gnt-cluster version
Software version: 2.15.2
Internode protocol: 2150000
Configuration format: 2150000
OS api version: 20
Export interface: 0
VCS version: (ganeti) version 2.15.2-3

Regards,

Dani

[candlerb]

Probably best asked on the synnefo group, not the ganeti one.

AFAIK, snf-image-creator will entirely remove the swap partition if it's the last one, and snf-image adds a new one.  So if you didn't do the shrink step, this would explain why you have two swap partitions.

I guess it might be a limitation of resize2fs on your Ubuntu 18.04 filesystem, maybe resize4fs is required instead?

[Dani García]

I agree, I will try to ask in synnefo group when I can (my membership is still pending).

Yes, I understand the problem if I don't remove the swap partition, but if I remove it, using "Shrink" or even manually, I always have the error described.

Thanks for the tip of resize4fs. I think it is related to that tool or similar, because I had to upgrade e2fsck to "Shrink" the image using snf-image-creator. I think the version of the "helper" VM is older and have some kind of problem with Ubuntu 18.04.

Maybe someone has had the same problem or have any other idea.

[Benjamin Redling]

On 03/07/18 12:13, candlerb wrote:
> Probably best asked on the synnefo group, not the ganeti one.

maybe I don't remember it correctly but I thought snf-image might become
part of ganeti?

Apart from that there wasn't a reaction to an issue with the signing
keys for a month (Karten Heymann June, 4th; have that too) now and as
long as that isn't resolved I would recommend anyone to stay away from
snf-* for the future
-- I was really happy with snf-image :(

Regards,
Benjamin
--
FSU Jena | JULIELab.de/Staff/Redling

[candlerb]

On Tuesday, 3 July 2018 11:39:10 UTC+1, Benjamin Redling wrote:

maybe I don't remember it correctly but I thought snf-image might become
part of ganeti?

I don't remember that, but there could have been a proposal I missed.

There *is* a long-standing proposal for a redesign of ganeti's own OS installation mechanism:

http://docs.ganeti.org/ganeti/master/html/design-os.html

Many of the features of that are similar to the way snf-image does it (e.g. untrusted scripts run in separate helper VM)

 

Apart from that there wasn't a reaction to an issue with the signing
keys for a month (Karten Heymann June, 4th; have that too)

This thread? https://groups.google.com/forum/#!topic/synnefo/Ws5kMeaoBWQ

[Benjamin Redling]

On 03/07/18 13:36, candlerb wrote:
> On Tuesday, 3 July 2018 11:39:10 UTC+1, Benjamin Redling wrote:

>> maybe I don't remember it correctly but I thought snf-image might become
>> part of ganeti?

> There *is* a long-standing proposal for a redesign of ganeti's own OS
> installation mechanism:
> http://docs.ganeti.org/ganeti/master/html/design-os.html

> Many of the features of that are similar to the way snf-image does it (e.g.
> untrusted scripts run in separate helper VM)

AFAIK not an official proposal; As far as I remembered suggested by
(former) GRNET guys during the last GanetiCon@Google in Dublin (2016)?

>> Apart from that there wasn't a reaction to an issue with the signing
>> keys for a month (Karten Heymann June, 4th; have that too)

> This thread? https://groups.google.com/forum/#!topic/synnefo/Ws5kMeaoBWQ

Yes, thanks for the details (SHA-1).
(Seems when a central tool says "invalid signature" instead of stating
"too weak signature" I fall back into bureaucracy mode and stop
questioning things.)


--
FSU Jena | JULIELab.de/Staff/Redling/

[Simon Deziel]

Hi Dani,

I'm not familiar with snf-image but the problem may be related to [1]?
Also, I don't know if that plays a role here but by default Ubuntu no
longer creates a swap partition but uses a swap file, unless you
instructed it otherwise.

HTH,
Simon

1: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997

On 2018-07-03 03:38 AM, Dani García wrote:
> Hi,
>
> I'm trying to generate the snf-image for Ubuntu Sever 18.04 because isn't
> in the list of images listed in
> https://www.synnefo.org/docs/snf-image/latest/usage.html#sample-images. I'm
> using the image
> http://cdimage.ubuntu.com/ubuntu/releases/18.04/release/ubuntu-18.04-server-amd64.iso
> and following the steps of
> https://www.synnefo.org/docs/snf-image-creator/latest/usage.html#creating-a-new-image.
>
> I have installed the most basic Ubuntu configuration with two partitios as
> suggested: one primary for root (/) and one primary for swap. Then, with
> snf-image-creator, I apply the default steps in "Expert" -> "Customize" ->
> "Sysprep" and the las step, called "Shrink" deletes de swap partition and
> save enough information to recreate it, as described on
> https://www.synnefo.org/docs/snf-image-creator/latest/usage.html#image-partition-schemes-and-shrinking.
>
> Everything is ok, no errors, but when I copy the image to all my Ganeti
> nodes (/var/lib/snf-image/) and try to create a new instance, I get the
> following error:
>

> *# gnt-instance add -t plain -o snf-image+default -O

> img_format=diskdump,img_id=ubuntu18.diskdump,img_properties='{"EXCLUDE_TASK_ConfigureNetwork":"yes"\,"OSFAMILY":"linux"\,"ROOT_PARTITION":"1"\,"USERS":"root"\,"SWAP":"2:1024"}'
> --disk=0:size=6G --no-name-check --no-ip-check -H
> kvm:vnc_bind_address=0.0.0.0,kernel_path="" -B memory=1G,vcpus=1 --net

> 0:link=br-lan --no-wait-for-sync ubuntu18*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Mon Jul 2 17:36:27 2018 * disk 0, size 6.0GMon Jul 2 17:36:27 2018 *
> creating instance disks...Mon Jul 2 17:36:29 2018 adding instance testub18
> to cluster configMon Jul 2 17:36:29 2018 adding disks to cluster configMon

> Jul 2 17:36:29 2018 * running the instance OS create scripts...Failure:
> command execution error:Could not add os for instance testub18 on node
> node1.zoconet.es: OS create script failed (exited with exit code 1), last
> lines in the log file:[MONITOR] {"subtype": "task-start", "task":
> "FixPartitionTable", "type": "image-helper", "timestamp":
> 1530545811.853033}[MONITOR] {"subtype": "task-end", "task":
> "FixPartitionTable", "type": "image-helper", "timestamp":
> 1530545812.372859}HELPER: 2018:07:02-15:36:51.876028528 run-parts:
> executing
> /usr/lib/snf-image-helper/tasks/20FilesystemResizeUnmounted[MONITOR]
> {"subtype": "task-start", "task": "FilesystemResizeUnmounted", "type":
> "image-helper", "timestamp": 1530545812.411796}HELPER:
> 2018:07:02-15:36:51.975698543 resize2fs 1.42.12 (29-Aug-2014)HELPER:
> 2018:07:02-15:36:51.979399004 Couldn't find valid filesystem

> superblock.HELPER: 2018:07:02-15:36:51.981825425 /sbin/resize2fs:

> Filesystem has unsupported read-only feature(s) while trying to open
> /dev/vdb1[MONITOR] {"subtype": "error", "type": "image-helper", "stderr":
> "resize2fs 1.42.12 (29-Aug-2014)\n/sbin/resize2fs: Filesystem has
> unsupported read-only feature(s) while trying to open /dev/vdb1\r\n",
> "timestamp": 1530545812.49461}HELPER: 2018:07:02-15:36:51.995649973
> run-parts: /usr/lib/snf-image-helper/tasks/20FilesystemResizeUnmounted
> exited with return code 1HELPER: sysrq: SysRq : Power OffHELPER: reboot:

> Power down2018:07:02-15:36:53.604862907 VM STOP[INFO] Customization VM

> exited normally.[MONITOR] {"messages": ["Customization VM exited
> normally."], "type": "image-info", "timestamp": 1530545813.641424}[INFO]
> Checking customization status...[MONITOR] {"messages": ["Checking
> customization status..."], "type": "image-info", "timestamp":
> 1530545813.697373}[INFO] Customization status is: [MONITOR] {"messages":
> ["Customization status is:"], "type": "image-info", "timestamp":
> 1530545813.733752}[ERROR] Image customization failed.[MONITOR] {"messages":
> ["Image customization failed."], "type": "image-error", "timestamp":

> 1530545813.770243}*

>
> If I avoid the "Shrink" step, which left the partitions untouched, it
> creates the VM, but I also have a problem because the partition that grows
> is the swap one, and it also creates a new swap partition:
>
>

> */dev/vda1 * 2048 ... ... 2.6G 83 Linux/dev/vda2 ... ... ...
> 2.4G 82 Linux swap / Solaris *# The one that grows
> */dev/vda3 ... ... ... 1G 82 Linux swap / Solaris*

>
> I don't understand why in the first case it tries to read /dev/vdb1 when it
> doesn't exists. My Ganeti version, running in Ubuntu 16.04, is:
>
>
>
>
>
>
>

> *# gnt-cluster versionSoftware version: 2.15.2Internode protocol:
> 2150000Configuration format: 2150000OS api version: 20Export interface:
> 0VCS version: (ganeti) version 2.15.2-3*
>
> Regards,
>
> Dani
>

[Dani García]

Hi Simon,

Thanks for the comment. In fact I had to upgrade e2fsprogs to "shrink" de image using snf-image-creator because of that problem. I think the problem is that the helper VM used to create the instance in Ganeti doesn't understand the partitions created in Ubuntu 18.04 (above 16.10 according to your link) and try to find the next one (vdb1). Maybe someone can confirm that.

I will try the same question in synnefo list asap when I get the membership.

[Dani García]

Hi,

Finally I have found a workround to the problem: I have started a new instalation with a Ubuntu 16.04 ISO and, after the partitioning step, I have stopped the process and started the installation with Ubuntu 18.04, using the same disk. Then I have used the created partitions without formating them and I was able to "shrink" de image and create the snf-image of 18.04. I have tested it on Ganeti and it works... it resizes the root partition and creates the swap partition.

If someone has a better solution, please share it.

Regards,

Dani

[Alexandros Afentoulis]

Hi,

I just created a Bionic 18.04 ganeti instance following these steps:

a) Fetch the cloud image from upstream:

> ➜ test0-2709.yp1 ~ # wget -c https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img

b) Use snf-mkimage (provided by snf-image-creator) to create a
"snf-image" friendly image:

> ➜ test0-2709.yp1 ~ # snf-mkimage --print-syspreps -o bionic-server-cloudimg-amd64-out.img bionic-server-cloudimg-amd64.img

c) place the output image in a ganeti nodes /var/lib/snf-image, then
create instance:

> ➜ gnt9-1001.yp3 ~ # gnt-instance add -o snf-image+default -n gnt9-1001.yp3.grnet.gr -O img_format=diskdump,img_id=ubuntu-bionic-server-cloudimg-amd64-out.img,img_properties='{"CLOUD_INIT": "yes"}',img_passwd='koko' -t sharedfile --disk=0:size=10G -B memory=2G --net 0:network=public_125,ip=pool --no-name-check --no-ip-check alexaf-bionic-cloud.grnet.gr

I verified that worked.

Additionally, if one wanted a swap partition they could use the relevant
IMG_PROPERTIES property, eg: {"SWAP":"2:512"}

Regarding the snf-image comments, an old version of snf-image helper vm
might indeed result in problems with recent distributions (say specific
filesystem operations). I wish I had an authoritative answer about the
snf-image status. I don't.

Hope I helped,
Alexandros

[Dani García]

Hi Alexandros,

Thank you very much for your help. Hope we can see a newer version of snf-image (and its helper vm) soon.

Regards,

Dani

[candlerb]

Hi Alexandros,

What OS were you running snf-mkimage under?  I tried to follow your steps inside an Ubuntu 16.04 container, and I got the following error:

Preparing system for image creation:

Mounting the media read-write ... done

(1/14)  Removing sensitive user data

(2/14)  Removing files under /tmp and /var/tmp

(3/14)  Disabling predictable network interface naming

(4/14)  Clearing local machine ID configuration file

(5/14)  Removing swap entry from fstab

(6/14)  Cleaning up password & locking all user accounts

(7/14)  Removing files under /var/cache

(8/14)  Disabling IPv6 privacy extensions

(9/14)  Change boot menu timeout to 10 seconds

(10/14) Emptying all files under /var/log

(11/14) Removing persistent network interface names

(12/14) Replacing fstab & grub non-persistent device references

(13/14) Fixing acpid powerdown action

Warning: No acpi power button event found!

Umounting the media ... done

(14/14) Shrinking image (may take a while)

cleaning up ...

Traceback (most recent call last):

  File "/usr/bin/snf-mkimage", line 9, in <module>

    load_entry_point('snf-image-creator==0.11', 'console_scripts', 'snf-mkimage')()

  File "/usr/lib/python2.7/dist-packages/image_creator/main.py", line 541, in main

    sys.exit(image_creator(options, out))

  File "/usr/lib/python2.7/dist-packages/image_creator/main.py", line 437, in image_creator

    image.os.do_sysprep()

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 479, in do_sysprep

    exec_sysprep(cnt, size, task)

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 469, in exec_sysprep

    task()

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 94, in inner

    return method(self)

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/linux.py", line 483, in _shrink

    device = self.image.shrink()

  File "/usr/lib/python2.7/dist-packages/image_creator/image.py", line 462, in shrink

    self.g.e2fsck(part_dev, forceall=1)

  File "/usr/lib/python2.7/dist-packages/guestfs.py", line 2333, in e2fsck

    r = libguestfsmod.e2fsck (self._o, device, correct, forceall)

RuntimeError: e2fsck: e2fsck 1.42.13 (17-May-2015)

/dev/sda1 has unsupported feature(s): metadata_csum

e2fsck: Get a newer version of e2fsck! 

There doesn't seem to be a newer e2fsprogs in backports:

root@snf-image:~# dpkg-query -l e2fsprogs

Desired=Unknown/Install/Remove/Purge/Hold

| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)

||/ Name              Version       Architecture  Description

+++-=================-=============-=============-========================================

ii  e2fsprogs         1.42.13-1ubun amd64         ext2/ext3/ext4 file system utilities

root@snf-image:~# apt-get install -t xenial-backports e2fsprogs

Reading package lists... Done

Building dependency tree

Reading state information... Done

e2fsprogs is already the newest version (1.42.13-1ubuntu1).

0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.

So did you get it from somewhere else, or are you using something newer on the host OS?

Debian Jessie has an older version of e2fsprogs (1.42.12) but Jessie Backports has a newer one (1.43.3)

[candlerb]

Tried again using a Jessie container, upgraded to e2fsprogs from jessie-backports, but got a different error:

Preparing system for image creation:

Mounting the media read-write ... done

(1/14)  Removing sensitive user data

(2/14)  Removing files under /tmp and /var/tmp

(3/14)  Disabling predictable network interface naming

(4/14)  Clearing local machine ID configuration file

(5/14)  Removing swap entry from fstab

(6/14)  Cleaning up password & locking all user accounts

(7/14)  Removing files under /var/cache

(8/14)  Disabling IPv6 privacy extensions

(9/14)  Change boot menu timeout to 10 seconds

(10/14) Emptying all files under /var/log

(11/14) Removing persistent network interface names

(12/14) Replacing fstab & grub non-persistent device references

(13/14) Fixing acpid powerdown action

Warning: No acpi power button event found!

Umounting the media ... done

(14/14) Shrinking image (may take a while)

cleaning up ...

Traceback (most recent call last):

  File "/usr/bin/snf-mkimage", line 9, in <module>

    load_entry_point('snf-image-creator==0.11.1', 'console_scripts', 'snf-mkimage')()

  File "/usr/lib/python2.7/dist-packages/image_creator/main.py", line 554, in main

    sys.exit(image_creator(options, out))

  File "/usr/lib/python2.7/dist-packages/image_creator/main.py", line 437, in image_creator

    image.os.do_sysprep()

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 479, in do_sysprep

    exec_sysprep(cnt, size, task)

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 469, in exec_sysprep

    task()

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 94, in inner

    return method(self)

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/linux.py", line 483, in _shrink

    device = self.image.shrink()

  File "/usr/lib/python2.7/dist-packages/image_creator/image.py", line 495, in shrink

    with self.raw_device(readonly=False) as raw:

  File "/usr/lib/python2.7/dist-packages/image_creator/image.py", line 244, in __enter__

    img.nbd.connect(readonly)

  File "/usr/lib/python2.7/dist-packages/image_creator/util.py", line 185, in connect

    self.modprobe('nbd', 'max_part=16')

  File "/usr/lib/python2.7/dist-packages/sh.py", line 769, in __call__

    return RunningCommand(cmd, call_args, stdin, stdout, stderr)

  File "/usr/lib/python2.7/dist-packages/sh.py", line 330, in __init__

    self.wait()

  File "/usr/lib/python2.7/dist-packages/sh.py", line 334, in wait

    self._handle_exit_code(self.process.wait())

  File "/usr/lib/python2.7/dist-packages/sh.py", line 348, in _handle_exit_code

    self.process.stderr

sh.ErrorReturnCode_1:

  RAN: '/sbin/modprobe nbd max_part=16'

  STDOUT:

  STDERR:

modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-128-generic/modules.dep.bin'

I suspect this is because I'm running it in a lxd container; 4.4.0-128-generic is the kernel on the host.  It seems snf-mkimage is making assumptions about the host kernel being available in the current filesystem.  I expect it would work if I made a full-fat jessie VM to run snf-mkimage inside.

Finally, I made a frankencontainer, containing Ubuntu 16.04 but with e2fslibs and e2fsprogs 1.43.3-1~bpo8+1_amd64.deb from jessie backports. (Maybe bionic would have been OK)

New error:

(14/14) Shrinking image (may take a while)

cleaning up ...

Traceback (most recent call last):

  File "/usr/bin/snf-mkimage", line 9, in <module>

    load_entry_point('snf-image-creator==0.11', 'console_scripts', 'snf-mkimage')()

  File "/usr/lib/python2.7/dist-packages/image_creator/main.py", line 541, in main

    sys.exit(image_creator(options, out))

  File "/usr/lib/python2.7/dist-packages/image_creator/main.py", line 437, in image_creator

    image.os.do_sysprep()

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 479, in do_sysprep

    exec_sysprep(cnt, size, task)

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 469, in exec_sysprep

    task()

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/__init__.py", line 94, in inner

    return method(self)

  File "/usr/lib/python2.7/dist-packages/image_creator/os_type/linux.py", line 483, in _shrink

    device = self.image.shrink()

  File "/usr/lib/python2.7/dist-packages/image_creator/image.py", line 495, in shrink

    with self.raw_device(readonly=False) as raw:

  File "/usr/lib/python2.7/dist-packages/image_creator/image.py", line 244, in __enter__

    img.nbd.connect(readonly)

  File "/usr/lib/python2.7/dist-packages/image_creator/util.py", line 172, in connect

    self.modprobe('nbd', 'max_part=16')

  File "/usr/lib/python2.7/dist-packages/sh.py", line 1021, in __call__

    return RunningCommand(cmd, call_args, stdin, stdout, stderr)

  File "/usr/lib/python2.7/dist-packages/sh.py", line 486, in __init__

    self.wait()

  File "/usr/lib/python2.7/dist-packages/sh.py", line 500, in wait

    self.handle_command_exit_code(exit_code)

  File "/usr/lib/python2.7/dist-packages/sh.py", line 516, in handle_command_exit_code

    raise exc(self.ran, self.process.stdout, self.process.stderr)

sh.ErrorReturnCode_1:

  RAN: '/sbin/modprobe nbd max_part=16'

  STDOUT:

  STDERR:

modprobe: ERROR: could not insert 'nbd': Function not implemented

Is it trying to install the nbd module locally? Why??  Of course, it cannot do that inside a container (and nor would I want it to mess with my host)

This is harder than I was hoping :-(

I don't want to install snf-image-creator directly on the host, as it has 150+ dependent packages, and this is supposed to be a "clean" host primarily for running VMs.  And in any case, the host is 16.04, and I already know that e2fsprogs from 16.04 is too old.

[candlerb]

FYI, I got snf-mkimage to run by installing a full-fat Jessie VM, installing snf-image-creator inside it, and updating e2fsprogs from backports.

...

(13/14) Fixing acpid powerdown action

Warning: No acpi power button event found!

Umounting the media ... done

(14/14) Shrinking image (may take a while)

Image size is 1590MB

Calculating md5sum ... 3017062f02e6d39425101506177b91d0

Dumping image file ... image file bionic-server-cloudimg-amd64-out.img was successfully created

Dumping metadata file ... done

Dumping md5sum file ... done

Dumping variant file ... done

cleaning up ...

snf-image-creator exited without errors

The generated image file is huge:

root@jessie:~# ls -ls

total 1957212

 329284 -rw-r--r-- 1 root root  337182720 Jul  6 22:08 bionic-server-cloudimg-amd64.img

1627916 -rw-r--r-- 1 root root 1666981888 Jul  6 22:10 bionic-server-cloudimg-amd64-out.img

      4 -rw-r--r-- 1 root root         70 Jul  6 22:10 bionic-server-cloudimg-amd64-out.img.md5sum

      4 -rw-r--r-- 1 root root        294 Jul  6 22:10 bionic-server-cloudimg-amd64-out.img.meta

      4 -rw-r--r-- 1 root root        337 Jul  6 22:10 bionic-server-cloudimg-amd64-out.img.variant

I think this is because the image isn't compressed.  The partitioning looks odd too:

root@jessie:~# file bionic-server-cloudimg-amd64-out.img

bionic-server-cloudimg-amd64-out.img: DOS/MBR boot sector, extended partition table (last)

root@jessie:~# fdisk bionic-server-cloudimg-amd64-out.img

Welcome to fdisk (util-linux 2.25.2).

Changes will remain in memory only, until you decide to write them.

Be careful before using the write command.

Command (m for help): p

Disk bionic-server-cloudimg-amd64-out.img: 1.6 GiB, 1666981888 bytes, 3255824 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier: 926E813E-A0D1-472B-A1D0-FDD7A79A0B5B

Device                                  Start     End Sectors  Size Type

bionic-server-cloudimg-amd64-out.img1  227328 3253775 3026448  1.5G Linux filesystem

bionic-server-cloudimg-amd64-out.img14   2048   10239    8192    4M BIOS boot

bionic-server-cloudimg-amd64-out.img15  10240  227327  217088  106M EFI System

Partition table entries are not in disk order.

Command (m for help): q

But actually: if I create a ganeti instance from this with -s 4G, it does automatically extend the partition vda1 to nearly 4G (of which 954M is used), leaving small vda14 and vda15 partitions.

Networking doesn't work though: /etc/netplan is empty.  There is '/etc/network/interfaces' asking for dhcp, but since ifupdown isn't installed it doesn't do anything.  There is also '/etc/network/interfaces.snf-image-796' which contains the text telling you that netplan supercedes this.

But this can be worked around using IMG_PERSONALITY to load a default netplan config:

IMG_PERSONALITY='[{

"path":"/etc/netplan/default.yaml",

"owner":"root",

"group":"root",

"mode":420,

"contents":"

bmV0d29yazoKICB2ZXJzaW9uOiAyCiAgZXRoZXJuZXRzOgogICAgZXRoMDoKICAgICAgZGhjcDQ6

IHRydWUK

"}]'

Regards,

Brian.

[Alexandros Afentoulis]

On 07/06/2018 05:16 PM, candlerb wrote:
> Hi Alexandros,
>
> What OS were you running snf-mkimage under?  I tried to follow your
> steps inside an Ubuntu 16.04 container, and I got the following error:
>

[snip]

Hi Brian,

this is my working environment:

> ➜ test0-2709.yp1 ~/test # cat /etc/debian_version
> 9.4

> ➜ test0-2709.yp1 ~/test # dpkg -l | grep snf-image
> ii snf-image 0.23.1-1~jessie all Image Based Ganeti OS Provider
> ii snf-image-creator 0.11-1~jessie all Synnefo Image Creator

Issuing the commands referenced in my previous email I end up with:

> ➜ test0-2709.yp1 ~/test # ls -lh
> total 1.9G
> -rw-r--r-- 1 root root 322M Jun 30 22:46 bionic-server-cloudimg-amd64.img
> -rw-r--r-- 1 root root 1.6G Jul 9 11:15 bionic-server-cloudimg-amd64-out.img
> -rw-r--r-- 1 root root 70 Jul 9 11:15 bionic-server-cloudimg-amd64-out.img.md5sum
> -rw-r--r-- 1 root root 292 Jul 9 11:15 bionic-server-cloudimg-amd64-out.img.meta

Cheers

[candlerb]

And what version of e2fsprogs?

[Alexandros Afentoulis]

On 07/06/2018 05:16 PM, candlerb wrote:

> Hi Alexandros,
>
> What OS were you running snf-mkimage under?  I tried to follow your
> steps inside an Ubuntu 16.04 container, and I got the following error:
>

Hi Brian,

sorry for lagging behind

[snip]

> "/usr/lib/python2.7/dist-packages/image_creator/os_type/linux.py", line
> 483, in _shrink
>     device = self.image.shrink()
>   File "/usr/lib/python2.7/dist-packages/image_creator/image.py", line
> 462, in shrink
>     self.g.e2fsck(part_dev, forceall=1)
>   File "/usr/lib/python2.7/dist-packages/guestfs.py", line 2333, in e2fsck
>     r = libguestfsmod.e2fsck (self._o, device, correct, forceall)
> RuntimeError: e2fsck: e2fsck 1.42.13 (17-May-2015)
> /dev/sda1 has unsupported feature(s): metadata_csum
> e2fsck: Get a newer version of e2fsck! 
>
> There doesn't seem to be a newer e2fsprogs in backports:
>

>> And what version of e2fsprogs?

[snip]

So, snf-image-creator leverages libguestfs to perform modifications on
disk images. This is also visible in the previously pasted trace of yours.

I would say the packages you're interested in are:

> libguestfs0
> python-guestfs

rmadison tells me we have both of them in Debian Stretch, version 1:1.34.6-2

Probably Ubuntu Bionic image features a filesystem that needs that
version of libguestfs.

Hope I helped,
Alex