Bug 1115728 - Creating ubuntu lxc container in fedora 20 is failing
Summary: Creating ubuntu lxc container in fedora 20 is failing
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lxc
Version: 20
Hardware: All
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Thomas Moschny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-03 00:36 UTC by codingfreak
Modified: 2015-03-03 21:07 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-14 06:59:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description codingfreak 2014-07-03 00:36:37 UTC
Description of problem:

When I am trying to create a ubuntu lxc container in Fedora 20 it fails with below error message

# lxc-create -t ubuntu -n ubuntutest
Checking cache download in /var/cache/lxc/precise/rootfs-amd64 ...
Installing packages in template: ssh,vim,language-pack-en
Downloading ubuntu precise minimal ...
which: no qemu-debootstrap in
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/usr/sbin:/usr/bin:/sbin:/bin)
I: Keyring file not available at
/usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https
mirror https://mirrors.kernel.org/debian
I: Retrieving Release
E: Failed getting release file
https://mirrors.kernel.org/debian/dists/precise/Release
lxc_container: container creation template for ubuntutest failed
lxc_container: Error creating container ubuntutest


Version-Release number of selected component (if applicable):

lxc version 1.0.3 from rawhide

How reproducible:

Try below command

lxc-create -t ubuntu -n ubuntutest

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:

Creating lxc container based on ubuntu template should be successful in fedora 20

Additional info:

Comment 1 Richard W.M. Jones 2014-07-03 07:58:58 UTC
There seem to be two errors here.  The second is:

E: Failed getting release file
https://mirrors.kernel.org/debian/dists/precise/Release

This file doesn't exist.  Could be a bug in debootstrap?

The first one is about the missing qemu-debootstrap binary.
There is no qemu-debootstrap binary in Fedora's debootstrap
package:

http://koji.fedoraproject.org/koji/rpminfo?rpmID=4983129

I checked on a Debian/testing machine and this binary comes
from the 'qemu' package.  It is just a random binary that
Debian have added to qemu, not part of qemu upstream.
(I do NOT think this should be packaged in Fedora's qemu.)

Comment 2 Jan Včelák 2014-07-03 16:59:11 UTC
> E: Failed getting release file
> https://mirrors.kernel.org/debian/dists/precise/Release

Yes, the source should be: https://mirrors.kernel.org/ubuntu/dists/precise/Release

But I think this is a problem of lxc/qemu-debootstrap, which is invoking debootstrap and not debootstrap itself. The source mirror can be specified on debootstrap command line and installation of precise into a chroot works fine for me.

The qemu-debootstrap is obviously not packaged in Fedora. I'm switching this bugreport back to lxc, which is a source of the problem.

Comment 3 Thomas Moschny 2014-08-08 12:05:08 UTC
First, failing "which qemu-debootstrap" is only a cosmetic issue, the lxc-ubuntu template continues and simply uses debootstrap.

Second, it is unclear to me, where the wrong URL comes from, because the lxc-ubuntu tenplate is using http://archive.ubuntu.com/ubuntu, http://security.ubuntu.com/ubuntu, and http://ports.ubuntu.com/ubuntu-ports.

Maybe that URL (mirrors.kernel.org) is hard-coded into debootstrap?

Comment 4 Thomas Moschny 2014-08-08 12:06:14 UTC
Also, please verify the problem is still present with
https://admin.fedoraproject.org/updates/lxc-1.0.5-2.fc20

Comment 5 Thomas Moschny 2014-09-14 06:59:42 UTC
Closing, please re-open if the problem persists.

Comment 6 notrightnow 2015-01-23 00:27:06 UTC
This problem still exists in Fedora 21 with lxc-1.0.7-1.fc21.x86_64 and debootstrap-1.0.66-1.fc21.noarch

Comment 7 Thomas Moschny 2015-03-03 21:07:48 UTC
This is now handled in bug 1194770.


Note You need to log in before you can comment on or make changes to this bug.