I'd like to propose that a small subset of LABEL values be added to the
Dockerfile, to support the generic labels defined here ->
I think adding name, version, release, architecture, build-date, vendor,
url and summary would be a good default set. There should not be any
impact for running containers with this added meta-data outside atomic,
and would help provide additional information that could be referenced
via atomic or cockpit.
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
This event has been changed.
Title: Fedora Release Tools Demo (Live Broadcast)
The hangout will be broadcast live & posted at
Q&A - #fedora-meeting
Purpose: The purpose of a demo is to show our stakeholders what we
completed this iteration, get feedback from them about the changes & set
some context and expectation with them about our direction.
Demo agenda & previous demos can be viewed here:
- Openshift origin on Fedora
- Pungi 4 compose
- Koji signed repos new features
- Fedora's PDC introduction
- Autocloud front end changes
...and some other goodies
When: Tue Dec 15, 2015 12pm - 1pm Eastern Time
Where: Hangout on Air / YouTube live stream
* acarter(a)redhat.com - organizer
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
cloud(a)lists.fedoraproject.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2015-12-16 from 17:00:00 to 18:00:00 UTC
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
#141: Vagrant-libvirt Failed for Fedora-Cloud-Atomic 23
Reporter: aalam | Owner:
Type: defect | Status: new
Priority: blocker | Milestone: Future
Component: --- | Keywords: meeting
I have reproduced same error on my local computer with
sudo python3 -m unittest tunirtests.cloudtests -v
sudo systemctl stop crond.service
sudo systemctl disable crond.service
I failed to ssh back to system after rebooting.
Ticket URL: <https://fedorahosted.org/cloud/ticket/141>
Fedora Cloud Working Group Ticketing System
Has anyone else run into this? I've never before run into this
problem, not any version of Server or Workstation. Just cloud, and
I've run into it several times in just a few days.
I'm using public-key authentication to ssh into a Fedora 23 Cloud
Atomic ISO installation upgraded to 23.29. This works most of the
time, until it doesn't and then I always get this.
[chris@f23m ~]$ ssh chris(a)10.0.0.15
PTY allocation request failed on channel 0
If I happen to have an existing login available, even if I restart
sshd the problem isn't fixed. The only fix I've found so far is a
reboot which is more than a bit disruptive. Any ideas?
In the journal host side, it records a bunch of audit stuff, but three
lines that seem particularly relevant yet not illuminating:
Dec 12 12:37:10 f23a.localdomain audit: USER_AVC pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='Unknown permission start for class system
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Dec 12 12:27:25 f23a.localdomain sshd: error: openpty: No such
file or directory
Dec 12 12:27:25 f23a.localdomain sshd: error: session_pty_req:
session 0 alloc failed
I'd file a bug but I don't even know what to file it against. The full
journal output is here:
At Flock and on this list and elsewhere, we've talked about making
Fedora Atomic our main edition-level deliverable (while still producing
Cloud Base as something akin to a Spin).
As I understand it, this is officially agreed, but not everyone is
really bought in. I'd like to advocate for and advance this further,
especially since Two Week Atomic is off the ground and running (see
https://getfedora.org/en/cloud/download/atomic.html — thanks
everyone!). Are we ready for the next steps, here?
Fedora Project Leader
OK instead of hijacking some other thread...(sorta too late).
# lsblk -f
NAME FSTYPE LABEL UUID
=E2=94=9C=E2=94=80sda1 vfat 5956-63D8
=E2=94=9C=E2=94=80sda2 btrfs f23a
PV VG Fmt Attr PSize PFree
/dev/sda4 VG lvm2 a-- 426.51g 126.36g
VG #PV #LV #SN Attr VSize VFree
VG 1 1 0 wz--n- 426.51g 126.36g
LV VG Attr LSize Pool Origin Data% Meta% Move
Log Cpy%Sync Convert
docker-pool VG twi-a-tz-- 300.00g 0.00 0.44
What I'd like to know how to do, is get docker to use the thin pool
setup here as backing, instead of Btrfs.
What I tried:
# cp /usr/lib/docker-storage-setup/docker-storage-setup
I then edited that file making one change such that VG=3DVG since that's
the name of the VG. So it still says to use
# systemctl status docker-storage-setup
=E2=97=8F docker-storage-setup.service - Docker Storage Setup
(/usr/lib/systemd/system/docker-storage-setup.service; enabled; vendor
Active: inactive (dead) since Thu 2015-12-10 01:09:06 MST; 45s ago
Process: 8008 ExecStart=3D/usr/bin/docker-storage-setup (code=3Dexited,
Main PID: 8008 (code=3Dexited, status=3D0/SUCCESS)
Dec 10 01:09:05 f23a.localdomain systemd: Starting Docker Storage Setup.=
Dec 10 01:09:05 f23a.localdomain docker-storage-setup: INFO:
Volume group backing root filesystem could not be determined
Dec 10 01:09:06 f23a.localdomain docker-storage-setup: Logical
volume "docker-pool" changed.
Dec 10 01:09:06 f23a.localdomain systemd: Started Docker Storage Setup.
# systemctl status docker
=E2=97=8F docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled;
vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2015-12-10 01:09:06 MST; 48=
Process: 8032 ExecStart=3D/usr/bin/docker daemon $OPTIONS
$DOCKER_STORAGE_OPTIONS $DOCKER_NETWORK_OPTIONS $INSECURE_REGISTRY
Main PID: 8032 (code=3Dexited, status=3D1/FAILURE)
Dec 10 01:09:06 f23a.localdomain systemd: Starting Docker
Application Container Engine...
Dec 10 01:09:06 f23a.localdomain docker:
msg=3D"[graphdriver] using prior storage driver \"btrfs\""
Dec 10 01:09:06 f23a.localdomain docker:
time=3D"2015-12-10T01:09:06.249931298-07:00" level=3Dfatal msg=3D"Error
starting daemon: SELinux is not supporte...h driver"
Dec 10 01:09:06 f23a.localdomain systemd: docker.service: Main
process exited, code=3Dexited, status=3D1/FAILURE
Dec 10 01:09:06 f23a.localdomain systemd: Failed to start Docker
Application Container Engine.
Dec 10 01:09:06 f23a.localdomain systemd: docker.service: Unit
entered failed state.
Dec 10 01:09:06 f23a.localdomain systemd: docker.service: Failed
with result 'exit-code'.
Hint: Some lines were ellipsized, use -l to show in full.
So there's a disconnect between docker-storage-setup, which is set to
use devicemapper and the volume group named VG, and docker.service
which continues to use the btrfs driver (and then fails for the known
reason that --selinux-enabled is set by default and that's not yet
working until the automatic chcon patch lands).
In the meantime I can just remove --selinux-enabled. But I'd like to
know how to redirect docker to use lvm thinp if that's possible.