Could you please add support for Void Linux (lxc template)?

CentOS 8 was released yesterday (https://lists.centos.org/pipermail/centos-announce/2019-September/023449.html).
Any chance of adding it?

Hi,

I would be interested in how you get this running on CentOS 8. You give the variant minimal, while this kind of isos is not available on the official repos.
And I am a bit stuck in getting this line to run in our environment, when configuring the release (8.1.1911) and variant (boot).

[root@jwta01a tmp]# distrobuilder build-dir /tmp/template foo
Error: Error while downloading source: Couldn't get name of iso
[root@jwta01a tmp]# head -n10 template
image:
  distribution: centos
  release: 8.1.1911

source:
  downloader: centos-http
  url: http://centos.mirror.iweb.ca
  variant: boot
  keys:
  # RPM-GPG-KEY-CentOS-6
  - |-

[root@jwta01a tmp]# curl http://centos.mirror.iweb.ca/8.1.1911/isos/x86_64/ | grep CentOS | grep href
<tr><td valign="top"><img src="/icons/unknown.gif" alt="[   ]"></td><td><a href="CentOS-8.1.1911-x86_64-boot.iso">CentOS-8.1.1911-x86_64-boot.iso</a></td><td align="right">2020-01-03 16:30  </td><td align="right">597M</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/unknown.gif" alt="[   ]"></td><td><a href="CentOS-8.1.1911-x86_64-boot.iso.manifest">CentOS-8.1.1911-x86_64-boot.iso.manifest</a></td><td align="right">2020-01-03 16:30  </td><td align="right">626 </td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/unknown.gif" alt="[   ]"></td><td><a href="CentOS-8.1.1911-x86_64-boot.torrent">CentOS-8.1.1911-x86_64-boot.torrent</a></td><td align="right">2020-01-14 10:32  </td><td align="right"> 24K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/unknown.gif" alt="[   ]"></td><td><a href="CentOS-8.1.1911-x86_64-dvd1.iso">CentOS-8.1.1911-x86_64-dvd1.iso</a></td><td align="right">2020-01-03 16:47  </td><td align="right">7.0G</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/unknown.gif" alt="[   ]"></td><td><a href="CentOS-8.1.1911-x86_64-dvd1.iso.manifest">CentOS-8.1.1911-x86_64-dvd1.iso.manifest</a></td><td align="right">2020-01-03 16:47  </td><td align="right">408K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/unknown.gif" alt="[   ]"></td><td><a href="CentOS-8.1.1911-x86_64-dvd1.torrent">CentOS-8.1.1911-x86_64-dvd1.torrent</a></td><td align="right">2020-01-14 10:32  </td><td align="right">282K</td><td>&nbsp;</td></tr>

release:8 does not work as well.

Any feedback would be welcome.

Hello,

I was wondering why the images for Ubuntu 16.04 are way lighter than the one provided by the remote https://cloud-images.ubuntu.com/releases ?
I can see for example that the snapd daemon is not included.

Thanks,

Required information

• Distribution: Ubuntu 18.04.4 LTS
• Versions:
  • Kernel version: 5.3.0-51-generic lxc/incus#44~18.04.2-Ubuntu SMP Thu Apr 23 14:27:18 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
  • LXC version: 4.0.1
  • LXD version: 4.0.1
  • lxd snap version: 4.0.1 14890
  • Storage backend in use: ZFS
  • image description: Ubuntu focal amd64 (20200505_07:42)

Issue description

I launched an ubuntu container with a cloud-init profile that should disable the creation of the "ubuntu" user. It works with image ubuntu:20.04, but does not work with images:ubuntu/focal/cloud
Other parts of cloud-init work in both cases.

Steps to reproduce

1. Create a "nousers" profile with the content:

config:
  user.user-data: |
    #cloud-config
    timezone: Europe/Athens
    users: {}
description: ""
devices: {}
name: nousers

(lxc profile create nousers; lxc profile edit nousers)

2. lxc launch images:ubuntu/focal/cloud -p default -p nousers u1
3. lxc exec u1 bash
4. ls /home
   Result: There is a directory /home/ubuntu
   Expected Result: /home should be empty

ubuntu:20.04, it works as expected:
lxc launch ubuntu:20.04 -p default -p nousers u2

Note that in both cases the timezone is set as specified. I also verified that additional users can be created with cloud-init.

Could you please add support for OpenWrt?

See also: https://gitlab.com/lramage94/lxc-templates/issues/1

When executing apt I get the following error - which breaks my cloud-init setup:

Hit:1 http://security.ubuntu.com/ubuntu focal-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease
Reading package lists... Error!
E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_focal_universe_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.

I notice the generated debian images on images.linuxcontainers.org are using the cdn.debian.net mirror and I was wondering about the benefits of switching to http.debian.net which is superior afaiu ?

Fedora 30 is out since last week. It would be useful to add Fedora 30 support in the LXD images published at https://images.linuxcontainers.org/.

Fedora 29 has been out since a few weeks. It would be great to have Fedora 29 containers at https://images.linuxcontainers.org/ available to use with lxd.

The images for Alpine edge target the 'v3.8' repos, instead of the 'edge' repos.

Steps

1. lxc launch images:alpine/edge/amd64 test
2. lxc exec test ash
3. cat /etc/apk/repositories

http://dl-cdn.alpinelinux.org/alpine/v3.8/main
http://dl-cdn.alpinelinux.org/alpine/v3.8/community

It should be:

http://dl-cdn.alpinelinux.org/alpine/edge/main
http://dl-cdn.alpinelinux.org/alpine/edge/community

It's not just that the URL's are wrong, the base packages installed are from v3.8 too.

Currently images.linuxcontainers.org only hosts debian images for jessie, wheezy, and sid.
Please could you also provide squeeze images for both amd64, and i386 architectures?

Thanks,
Ben

Alpine has an official armhf port, but images are currently not being built for it.

Also, version 3.4 was released last month.

Are there any blockers to releasing Opensuse 42.1 and 42.2 images ?

there's something off with how the centos/8/cloud variant is built:
when no authorized-keys is set in cloud-config, a warning message is shown in /var/log/cloud-init-output.log
but when authorized-keys is set, it doesn't seem to do anything: no authorized-keys is set for cloud-user

furthermore, i'd suggest adding "openssh-server" to the packages for the cloud variant, and start the sshd service, so that one can ssh into the container right away

please generate a aplinfo.dat that describes your available images, so that they can be used directly in Proxmox VE (automatic discovery, download and install).

basically it's a list of entries like:

Package: debian-10.0-standard
Version: 10.0-1
Type: lxc
OS: debian-10.0
Section: system
Maintainer: Proxmox Support Team <[email protected]>
Architecture: amd64
Location: system/debian-10.0-standard_10.0-1_amd64.tar.gz
md5sum: 5e66d2da77a034a8b6a60909a6d91c80
sha512sum: f19d5594fccc0514b46e83ef31202e083021a0ba412f740fd6790fa88b9a83704d83342cab8286fcdd0342a704291bf243d7223d780f18828d1ec86bceab843f
Infopage: http://pve.proxmox.com/wiki/Debian_10.0_Standard
Description: Debian 10.0 (standard)
 A small Debian Buster system including all standard packages.

you can find current example lists here:
http://download.proxmox.com/images/aplinfo.dat
https://releases.turnkeylinux.org/pve/aplinfo.dat

those files can also be signed provided signed or compressed.

aplinfo.dat parser: https://git.proxmox.com/?p=pve-manager.git;a=blob;f=PVE/APLInfo.pm;h=db32b5882b301346d814f5d0ce3352647e9b6b51;hb=HEAD

you already have all the information needed when building your images, so this seems to integrate with your build-chain quite easily.

I am starting to deploy Centos 8 LXD containers and I see that most of the time the container doesn't get an IPv4 address. it seems to be a race condition, because in a fairly fast host with an SSD it gets the address most of the time while in a slower host it doesn't get it most of the time.

The containers where created with the simple command
lxc init images:centos/8 centos8-test

I am not sure whether this is a problem of Centos 8 itself or LXD.

Please ignore

On Ubuntu 18.04.1 on DigitalOcean a fresh copy of fedora/28/amd64 does not start with an IPV4 address. Shouldn't this fail in the image test process? (

Steps I followed

Default lxd installation:

lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: 
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]: 
Create a new BTRFS pool? (yes/no) [default=yes]: 
Would you like to use an existing block device? (yes/no) [default=no]: 
Size in GB of the new loop device (1GB minimum) [default=15GB]: 
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: 
What should the new bridge be called? [default=lxdbr0]: 
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
Would you like LXD to be available over the network? (yes/no) [default=no]: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] 
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: 

Copy image

lxc image copy images:fedora/28/amd64 local: --copy-aliases
Image copied successfully!

Create container

lxc launch fedora/28/amd64 f28
Creating f28
Starting f28
root@do-hs-20180914:~# lxc list
+------+---------+------+-----------------------------------------------+------------+-----------+
| NAME |  STATE  | IPV4 |                     IPV6                      |    TYPE    | SNAPSHOTS |
+------+---------+------+-----------------------------------------------+------------+-----------+
| f28  | RUNNING |      | fd42:9296:8556:afc3:216:3eff:feb7:e6d8 (eth0) | PERSISTENT | 0         |
+------+---------+------+-----------------------------------------------+------------+-----------+

Update repos on container

lxc exec f28 bash 
[root@f28 ~]# dnf update
dnf update
Error: Failed to synchronize cache for repo 'updates'

Image info

 lxc image info fedora/28/amd64
Fingerprint: 909f5bb564bec4af28ed111a959b10a55b6746de50904c009f24e6468f24bc7c
Size: 60.40MB
Architecture: x86_64
Public: no
Timestamps:
    Created: 2018/10/04 00:00 UTC
    Uploaded: 2018/10/13 23:07 UTC
    Expires: never
    Last used: 2018/10/13 23:07 UTC
Properties:
    architecture: amd64
    description: Fedora 28 amd64 (20181004_01:27)
    os: Fedora
    release: 28
    serial: 20181004_01:27
Aliases:
    - fedora/28/default
    - fedora/28/default/amd64
    - fedora/28
    - fedora/28/amd64
Cached: no
Auto update: disabled
Source:
    Server: https://images.linuxcontainers.org
    Protocol: simplestreams
    Alias: fedora/28/amd64

Currently the OpenWrt images builds on snapshots but that's quite bad practice and people wants to target a more stable OpenWrt version.

I am very pleased to see a VM image for Alpine Linux 3.12. Unfortunately on the Raspberry Pi (Arm 64), it fails to boot.

It gets very far, but then gets stuck. Here are the last few lines from the console:-

[ 1.355424] PCI Interrupt Link [GSI1] enabled at IRQ 36
[ 1.360881] pcieport 0000:00:01.0: PME: Signaling with IRQ 42
[ 1.363813] pcieport 0000:00:01.0: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep+
[ 1.374613] pcieport 0000:00:01.1: PME: Signaling with IRQ 43
[ 1.377583] pcieport 0000:00:01.1: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep+
[ 1.390202] pcieport 0000:00:01.2: PME: Signaling with IRQ 44
[ 1.393175] pcieport 0000:00:01.2: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep+
[ 1.403115] pcieport 0000:00:01.3: PME: Signaling with IRQ 45
[ 1.406084] pcieport 0000:00:01.3: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep+
[ 1.417414] pcieport 0000:00:01.4: PME: Signaling with IRQ 46
[ 1.423119] pcieport 0000:00:01.4: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- LLActRep+
[ 1.433544] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 1.438771] cacheinfo: Unable to detect cache hierarchy for CPU 0
[ 1.441967] rtc-efi rtc-efi: registered as rtc0
[ 1.445018] registered taskstats version 1
[ 1.447412] Loading compiled-in X.509 certificates
[ 1.451811] Loaded X.509 cert 'Build time autogenerated kernel key: bdc7ce04d5acd77fd0a3891f9e7eca91341a188c'
[ 1.456663] Key type ._fscrypt registered
[ 1.458629] Key type .fscrypt registered
[ 1.461919] rtc-efi rtc-efi: setting system clock to 2020-07-06T17:28:21 UTC (1594056501)
[ 1.466356] Freeing unused kernel memory: 768K
[ 1.508944] Run /init as init process
[ 1.552344] SCSI subsystem initialized
[ 1.567662] ACPI: bus type USB registered
[ 1.569881] usbcore: registered new interface driver usbfs
[ 1.572581] usbcore: registered new interface driver hub
[ 1.575113] usbcore: registered new device driver usb
[ 1.582706] usbcore: registered new interface driver usb-storage
[ 1.939670] loop: module loaded
[ 2.004886] virtio-pci 0000:01:00.0: enabling device (0000 -> 0002)
[ 2.019077] virtio-pci 0000:01:00.2: enabling device (0000 -> 0002)
[ 2.028805] virtio-pci 0000:01:00.3: enabling device (0000 -> 0002)
[ 2.039045] virtio-pci 0000:01:00.4: enabling device (0000 -> 0002)
[ 2.049045] virtio-pci 0000:01:00.5: enabling device (0000 -> 0002)
[ 2.065785] virtio-pci 0000:03:00.0: enabling device (0000 -> 0002)
[ 2.103872] input: QEMU Virtio Keyboard as /devices/pci0000:00/0000:00:01.0/0000:01:00.2/virtio2/input/input0
[ 2.112889] input: QEMU Virtio Tablet as /devices/pci0000:00/0000:00:01.0/0000:01:00.3/virtio3/input/input1
[ 2.125541] scsi host0: Virtio SCSI HBA
[ 2.130480] scsi 0:0:0:1: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5
[ 2.171622] random: fast init done
[ 2.180487] sd 0:0:0:1: Power-on or device reset occurred
[ 2.185672] sd 0:0:0:1: [sda] 19531248 512-byte logical blocks: (10.00 GB/9.31 GiB)
[ 2.195497] sd 0:0:0:1: [sda] Write Protect is off
[ 2.199956] sd 0:0:0:1: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.257580] sda: sda1 sda2
[ 2.261807] sd 0:0:0:1: [sda] Attached SCSI disk
[ 2.325669] [drm] pci: virtio-gpu-pci detected at 0000:04:00.0
[ 2.328211] [drm] virgl 3d acceleration not supported by host
[ 2.330792] [drm] EDID support available.
[ 2.334358] [TTM] Zone kernel: Available graphics memory: 228446 KiB
[ 2.337151] [TTM] Initializing pool allocator
[ 2.339525] [TTM] Initializing DMA pool allocator
[ 2.341593] [drm] number of scanouts: 1
[ 2.343296] [drm] number of cap sets: 0
[ 2.346437] [drm] Initialized virtio_gpu 0.1.0 0 for virtio8 on minor 0
[ 2.355174] Console: switching to colour frame buffer device 128x48
[ 2.378869] virtio_gpu virtio8: fb0: virtio_gpudrmfb frame buffer device
[ 2.715551] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)

Is it possible for LXC to build Debian mips* images now that they work properly (at least with the dev version of LXC)?

The arches are mips, mipsel and mips64el although mips64el only exists in stretch and sid.

Could you please add images for Alpine Linux?

I am assuming this is the right repository to place issues with the images obtained via the lxc-download template.

I am running a ubuntu xenial host and run off the lxc 3.0 release from https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/stable.
If I create container via lxc-create -n foobar -t download -- -d ubuntu -r trusty -a amd64 and start it via lxc-start, it doesn't obtain an IP address and generally it looks like a very bare bone linux host (no /var/log/syslog file to begin with).
Doing the same and replace -r trusty with -r xenial and I get a working container.

What's interesting - if I create the ubuntu trusty container via the ubuntu template (from the lxc-templates package in version 3.0), like so: lxc-create -n foobar -t ubuntu -- -r trusty -a amd64 I get a working container, obtaining IP addresses via DHCP from the host and with a working syslog file.

I am wondering now how the downloaded image is/can be different from the one I built via the ubuntu template.

Enviroment:
network: without dhcp, all interfaces need a static allocation

partial config with both methods of defining the dns resolvers

architecture: x86_64
config:
  boot.autostart: "1"
  image.architecture: amd64
  image.description: Debian buster amd64 (20200609_05:24)
  image.os: Debian
  image.release: buster
  image.serial: "20200609_05:24"
  user.network-config: "version: 1\nconfig:\n  - type: physical\n    name: eth0\n
    \   subnets:\n      - type: static\n        address: 10.53.2.170\n        netmask:
    255.255.255.0\n        gateway: 10.53.2.1\n        control: auto\n  - type: nameserver\n
    \   address: \n      - 10.53.1.101\n      - 10.53.1.102\n"
  user.user-data: |
    #cloud-config
    manage_etc_hosts: true
    manage_resolv_conf: true

    resolv_conf:
      nameservers:
        - 10.53.1.101
        - 10.53.1.102
      options:
        rotate: true
        timeout: 1
  volatile.base_image: 54d80ea17c872cc0964c55a219c1625375f313d25619aabd9e05936a5b1a2120

This results in:

• empty /etc/resolv.conf file, because the package resolvconf ( or alternative ) is missing
• slow boot, because of hardcoded eth0 dhcp in /etc/network/interfaces (https://github.com/lxc/lxc-ci/blob/master/images/debian.yaml#L856)

Hi, it seems the aforementioned VMs are broken. I can e.g. lxc launch images:debian/buster --vm and then lxc shell or lxc exec with it as expected. However if I try the same with images:debian/bullseye or /sid, I get Error: Failed to connect to lxd-agent. From the output of lxc ls, I can tell it's at least come up successfully and has an IPv4 and IPv6 address. Per lxc version, I have:

Client version: 4.2
Server version: 4.2

What work would need to be done to enable Arch Linux builds? I see, for example, the following:

• Template script requires the arch-install-scripts and pacman.
• Template script does some funky stuff with systemd service files, which isn't needed now, in my experience.
• Template script doesn't mask some services that shouldn't run in a container, like systemd-udevd.
• systemd has some issues with AppArmor and LXC, which breaks some vital services. A blocker for running, but no clue if it still can be built.

Current debian images cannot be easily used in an "automated" way because openssh-server is not installed/enabled and also cloud-init (issue #16) is missing.

This happens:-

BdsDxe: loading Boot0001 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/Scsi(0x0,0x1)
BdsDxe: failed to load Boot0001 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/Scsi(0x0,0x1): Access Denied

So then I disable secure boot and then this happens:-

Booting `openSUSE Tumbleweed'

Loading Linux 5.6.8-1-default ...
error: can't find command linuxefi'. Loading initial ramdisk ... error: can't find command initrdefi'.

Press any key to continue...

Failed to boot both default and fallback entries.

Press any key to continue...

What is the process for adding new distros? I would like to add NixOS images to the registry. I can write the build configurations myself, but want to make sure new distros are accepted first.

My main use case is getting Chrome OS laptops setup with Crostini, so if there are other registries that support this, please point me there.

More information at: https://nixos.org

The Fedora images published at https://images.linuxcontainers.org/ included versions of Fedora 26, 27 that are now gone. I understand that these versions are no longer supported by Fedora and therefore it makes sense not to offer them anymore. Unfortunately this has broken our workflow, where we use those images to test our software in different platforms used by the customers (including some which are no longer supported...).

It would be very useful if those "legacy" images are still available, maybe via a different image server like legacy.images.linuxcontainers.org and with the relevant disclaimer, of course.

Please add the ubuntu-core/18 images analogous to:

ubuntu-core/16 (3 more) | 7a17983ba54d | yes | Ubuntu-Core 16 amd64 (20190825_07:47) | x86_64 | 245.93MB | Aug 25, 2019 at 12:00am (UTC) |
+--------------------------------------+--------------+--------+----------------------------------------------+---------+----------+-------------------------------+
| ubuntu-core/16/i386 (1 more) | 4159a7c6fcfe | yes | Ubuntu-Core 16 i386 (20190825_07:47) | i686 | 239.77MB | Aug 25, 2019 at 12:00am (UTC) |

Thanks

simplestreams was advertising

"20180522_07:53": {"items": {"root.tar.xz": {"size": 78471080, "path": "images/ubuntu/artful/armhf/default/20180522_07:53/rootfs.tar.xz", "ftype": "root.tar.xz", "sha256": "89172b09e7fcaf0d321cd8cfeacffe7e8657bde75d2031868f3cd8431ec67915"}

but

Creating the container
error: Failed container creation:
 - https://images.linuxcontainers.org: Unable to fetch https://images.linuxcontainers.org/images/ubuntu/artful/armhf/default/20180522_07:53/lxd.tar.xz: 404 Not Found

was happening. This has just resolved itself, so it looks like a race or maybe a caching/CDN problem.

I already requested it in #4, but the old Alpine build template was not suitable for using with download template.

@stgraber: Not until someone converts the alpine linux template to something that can be used with the download template.

I rewrote the template and it was already merged (lxc/lxc#751), so I guess that now it can be added to CI. 😸

So that one don't have to patch bionic,

diff --git a/linker/linker.cpp b/linker/linker.cpp
index 54867dc..55ca67a 100644
--- a/linker/linker.cpp
+++ b/linker/linker.cpp
@@ -2401,11 +2401,11 @@ static ElfW(Addr) __linker_init_post_relocation(KernelArgumentBlock& args, ElfW(
   si->dynamic = nullptr;
   si->ref_count = 1;

-  ElfW(Ehdr)* elf_hdr = reinterpret_cast<ElfW(Ehdr)*>(si->base);
-  if (elf_hdr->e_type != ET_DYN) {
-    __libc_format_fd(2, "error: only position independent executables (PIE) are supported.\n");
-    exit(EXIT_FAILURE);
-  }
+  //ElfW(Ehdr)* elf_hdr = reinterpret_cast<ElfW(Ehdr)*>(si->base);
+  //if (elf_hdr->e_type != ET_DYN) {
+  //  __libc_format_fd(2, "error: only position independent executables (PIE) are supported.\n");
+  //  exit(EXIT_FAILURE);
+  //}

   // Use LD_LIBRARY_PATH and LD_PRELOAD (but only if we aren't setuid/setgid).
   parse_LD_LIBRARY_PATH(ldpath_env);

Fedora i386 have been offered in the past and continue to be useful for testing purposes. Since i386 is still offered and supported by Fedora, could you please add them to images.linuxcontainers.org again?

Just launch a new jessie container, and you end up with systemd-networkd in it running, utilizing an entire CPU core.

Usage message doesn't match code (target and timeout interchanged):

Since merging the new lxc-fedora template from lxc/lxc#1371 all builds for the fedora download image are failing. See https://jenkins.linuxcontainers.org/job/lxc-template-fedora/. This should be fixed:

Reason:

• Fedora 22: Not supported anymore by upstream, therefore aborted by lxc-fedora template:

 ==> Executing: "env root_password=root /usr/share/lxc/templates/lxc-fedora --path /build/containers/LXC_NAME --rootfs /build/containers/LXC_NAME/rootfs --name LXC_NAME -R 22 -a x86_64" in /
Error: Fedora release 22 is not supported. Set -R at least to 24.

• Fedora 23: Not supported anymore by upstream, therefore aborted by lxc-fedora template:

 ==> Executing: "env root_password=root /usr/share/lxc/templates/lxc-fedora --path /build/containers/LXC_NAME --rootfs /build/containers/LXC_NAME/rootfs --name LXC_NAME -R 23 -a x86_64" in /
Error: Fedora release 23 is not supported. Set -R at least to 24.

• Fedora 24: Failed to query mirrorlist in get_mirrors() for a valid repository URL to download bootstrap image:

==> Executing: "env root_password=root /usr/share/lxc/templates/lxc-fedora --path /build/containers/LXC_NAME --rootfs /build/containers/LXC_NAME/rootfs --name LXC_NAME -R 24 -a x86_64" in /
Checking cache download in /var/cache/lxc/fedora/24-x86_64/rootfs ... 
Downloading x86_64 rootfs for Fedora 24 ...
Non-Fedora host detected. Checking for bootstrap environment ... 
Setting up new Fedora 25 (x86_64) bootstrap environment.
Warning: Failed to get a mirror on try 1.
Trying again ... Warning: Failed to get a mirror on try 2.
Trying again ... Warning: Failed to get a mirror on try 3.
Trying again ... Warning: Failed to get a mirror on try 4.
Error: Failed to retrieve Fedora mirror URL. Please use '-m MIRROR' option.
Error: Fedora Bootstrap setup failed
Error: Failed to download Fedora 24 (x86_64)
Error: Failed to create Fedora container

Is it possible that outgoing HTTP requests are blocked for the build container?

i an new of linux, the testbuild-gcc program need file, deps/exercise , but where can i find the exercise file?
can anyone help me with it please!

https://discuss.linuxcontainers.org/t/lxd-virtual-machines-runing-perfectly-in-raspberry-pi-4/7706/3

Lxc binaries compiled using ndk give the above error when executed on android.

hey,
i'm trying to implement a mageia 6 distribution with LXC. i downloaded and installed lxc packages and i hope i havent missed anything. i want to ask if is there a way to do that especially that there is no image manifest or template related to mageia or mandriva linux.

Hello,

can you add Centos Stream, the rolling release of Centos, to the Centos images?

Informations about Centos Stream:

• https://www.redhat.com/en/blog/transforming-development-experience-within-centos
• https://wiki.centos.org/Manuals/ReleaseNotes/CentOSStream#Presenting_CentOS_Stream

The next RedHat EL 8 Minor Versions will be based on Centos Stream.
There is also the option to get upstream versions faster.

Kindly regards,
Raider700

Required information

Ubuntu Eoan

  driver: lxc
  driver_version: 4.0.1
  firewall: xtables
  kernel: Linux
  kernel_architecture: x86_64
  kernel_features:
    netnsid_getifaddrs: "true"
    seccomp_listener: "true"
    seccomp_listener_continue: "true"
    shiftfs: "false"
    uevent_injection: "true"
    unpriv_fscaps: "true"
  kernel_version: 5.3.0-46-generic
  lxc_features:
    cgroup2: "true"
    mount_injection_file: "true"
    network_gateway_device_route: "true"
    network_ipvlan: "true"
    network_l2proxy: "true"
    network_phys_macvlan_mtu: "true"
    network_veth_router: "true"
    seccomp_notify: "true"
  os_name: Ubuntu
  os_version: "19.10"
  project: default
  server: lxd
  server_clustered: false
  server_name: workstation
  server_pid: 2717202
  server_version: 4.0.0
  storage: dir
  storage_version: "1"

Issue description

After cloning a VM I ended up having the same IP address for the cloned VM:

rafaeldtinoco@workstation:~$ lxc list -c ns4t cluster01
+-----------+---------+-------------------------+-----------------+
|   NAME    |  STATE  |          IPV4           |      TYPE       |
+-----------+---------+-------------------------+-----------------+
| cluster01 | RUNNING | 10.250.97.142 (enp5s0)  | VIRTUAL-MACHINE |
|           |         | 10.250.94.166 (iscsi01) |                 |
|           |         | 10.250.93.100 (iscsi02) |                 |
+-----------+---------+-------------------------+-----------------+
rafaeldtinoco@workstation:~$ lxc list -c ns4t storage
+---------+---------+------------------------+-----------------+
|  NAME   |  STATE  |          IPV4          |      TYPE       |
+---------+---------+------------------------+-----------------+
| storage | RUNNING | 10.250.97.142 (enp5s0) | VIRTUAL-MACHINE |
|         |         | 10.250.94.99 (iscsi01) |                 |
|         |         | 10.250.93.99 (iscsi02) |                 |
+---------+---------+------------------------+-----------------+

Steps to reproduce

Clone a VM and make sure netplan io is configured with DHCP4 for a single interface, for example.

first machine

$ cat /etc/netplan/50-cloud-init.yaml
network:
    ethernets:
        enp5s0:
            dhcp4: true
            match:
                macaddress: 00:16:3e:af:c4:d6
            set-name: enp5s0
    version: 2
    renderer: networkd

(k)root@cluster01:.../systemd/netif/leases$ cat 2
# This is private data. Do not parse.
ADDRESS=10.250.97.142
NETMASK=255.255.255.0
ROUTER=10.250.97.1
SERVER_ADDRESS=10.250.97.1
NEXT_SERVER=10.250.97.1
BROADCAST=10.250.97.255
T1=1800
T2=3150
LIFETIME=3600
DNS=10.250.97.1
DOMAINNAME=lxd
HOSTNAME=cluster01
CLIENTID=ff49721f4700020000ab11df4ace466968c6ba

second machine

$ cat /etc/netplan/50-cloud-init.yaml
network:
    ethernets:
        enp5s0:
            dhcp4: true
            match:
                macaddress: 00:16:3e:82:48:57
            set-name: enp5s0
    version: 2
    renderer: networkd

(k)root@storage:.../systemd/netif/leases$ cat 2
# This is private data. Do not parse.
ADDRESS=10.250.97.142
NETMASK=255.255.255.0
ROUTER=10.250.97.1
SERVER_ADDRESS=10.250.97.1
NEXT_SERVER=10.250.97.1
BROADCAST=10.250.97.255
T1=1800
T2=3150
LIFETIME=3600
DNS=10.250.97.1
DOMAINNAME=lxd
HOSTNAME=storage
CLIENTID=ff49721f4700020000ab11df4ace466968c6ba

Information to attach

I believe that both machines ended up with the same CLIENTID because the systemd-networkd default is duid and not "mac". When I changed netplan.io to have:

dhcp-identifier: mac

Both got different IPs:

rafaeldtinoco@workstation:~$ lxc list -c ns4t cluster01
+-----------+---------+-------------------------+-----------------+
|   NAME    |  STATE  |          IPV4           |      TYPE       |
+-----------+---------+-------------------------+-----------------+
| cluster01 | RUNNING | 10.250.97.123 (enp5s0)  | VIRTUAL-MACHINE |
|           |         | 10.250.94.166 (iscsi01) |                 |
|           |         | 10.250.93.100 (iscsi02) |                 |
+-----------+---------+-------------------------+-----------------+
rafaeldtinoco@workstation:~$ lxc list -c ns4t storage
+---------+---------+------------------------+-----------------+
|  NAME   |  STATE  |          IPV4          |      TYPE       |
+---------+---------+------------------------+-----------------+
| storage | RUNNING | 10.250.97.143 (enp5s0) | VIRTUAL-MACHINE |
|         |         | 10.250.94.99 (iscsi01) |                 |
|         |         | 10.250.93.99 (iscsi02) |                 |
+---------+---------+------------------------+-----------------+

Perhaps dnsmasq in LXD should ignore clientids ? Or there should be a way to enforce netplan to always use mac for clientid ? Or something like it.

it's due to bad version 2 added in the wrong place in /etc/netplan/10-lxc.yaml:
network:
ethernets:
eth0: {dhcp4: true}
version: 2

Last 2 version have this issue:
Ubuntu bionic amd64 (20180502_09:49) 87b5c0fec8ff
Ubuntu bionic amd64 (20180503_07:43) 4d1d191c4128

Previous one was good:
Ubuntu bionic amd64 (20180501_03:49) 856aae255ed4

/etc/netplan/10-lxc.yaml:
network:
version: 2
ethernets:
eth0: {dhcp4: true}

Hello,

openSUSE Leap 15 has been released, so it would be nice to add a new job to build suitable images. The existing template should work fine. Thank you.

Hi there,

TL;DR

Any chance we can distribute desktops images through images.linuxcontainers.org based upon the existing cloud variants which support cloud-init?

• ubuntu/$RELEASE/desktop-default
  • based on: ubuntu/$RELEASE/cloud
  • additional package installed: ubuntu-desktop
• ubuntu/$RELEASE/desktop-kde
  • based on: ubuntu/$RELEASE/cloud
  • additional package installed: kubuntu-desktop
• centos/$RELEASE/...
  • ...
• debian...
• fedora...
• mint...

I'm aware this request implies the need of more resources (storage, bandwidth, ...) as desktop environments probably bump the size of the images quite a bit. So its totally understandable if this is out of scope for images.linuxcontainers.org - but as it would make things on end user machines way easier and a lot more reliable I dare to open this issue anyways ;)

Also I guess just for amd64 is enough - since its mainly for local development.

Further Information

I'm currently developing Tins, which should make access to a local, containerized desktop environment as easy as possible (for development, or if you are just curious).

While hacking together a rough solution I came across the issue, that installing the desktop environment packages using cloud-init is quite error prone and takes a loooooong time.

Now I'm wondering if we can deliver pre-built images with the base packages already installed through images.linuxcontainers.org - just like another variant. Any specific changes can then still be done on the client machine using cloud-init (as for adding users, devices etc.)

Since I think some weeks, I can't install anything inside archlinux. The error message is something about signatures.

On this image:
https://us.images.linuxcontainers.org/images/archlinux/current/amd64/default/20180203_01:27/rootfs.tar.xz

root@irae:~/plash/bin# pacman -Sy figlet
:: Synchronizing package databases...
 core                                               128.1 KiB  3.79M/s 00:00 [###########################################] 100%
 extra                                             1630.0 KiB  39.8M/s 00:00 [###########################################] 100%
 community                                            4.1 MiB  81.4M/s 00:00 [###########################################] 100%
resolving dependencies...
looking for conflicting packages...


Packages (1) figlet-2.2.5-2


Total Download Size:   0.09 MiB
Total Installed Size:  0.66 MiB


:: Proceed with installation? [Y/n] y
:: Retrieving packages...
 figlet-2.2.5-2-x86_64                               97.1 KiB  3.51M/s 00:00 [###########################################] 100%
(1/1) checking keys in keyring                                               [###########################################] 100%
error: GPGME error: Invalid crypto engine
(1/1) checking package integrity                                             [###########################################] 100%
error: GPGME error: Invalid crypto engine
error: figlet: missing required signature
:: File /var/cache/pacman/pkg/figlet-2.2.5-2-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Quack,

It has been released recently and having it at hand would be be very useful.

\_o<