Take a look at
http://dl.fedoraproject.org/pub/alt/stage/19-Beta-RC4/Images/
based on the Fedora Go/No-Go meeting, this is likely to be the Beta.
We have a couple of known issues in this beta release, which will probably cause us to respin some intermediate updated images between beta and final.
1. Cloud init hostname module broken
- This causes an about-one-minute delay on boot, during which ec2-user is not created.
Bug https://bugzilla.redhat.com/show_bug.cgi?id=964006
2. Growroot support not working right
- possibly related to the above? Definitely related to recent conversation.
- Currently still producing 10GB images until this is resolved
No bug yet but will file something soon.
3. qcow2 image is uncompressed
- this is due to the current release engineering workflow
- will be fixed one way or another for general release
Hi Matt,
Take a look at
http://dl.fedoraproject.org/pub/alt/stage/19-Beta-RC4/Images/
based on the Fedora Go/No-Go meeting, this is likely to be the Beta.
Thanks for this! I took it for a spin in OpenStack and here are my observations:
1) The hostname is not set correctly. See my updates to https://bugzilla.redhat.com/show_bug.cgi?id=964006. Looks to me like a systemd/selinux issue.
2) The root partition is not resized. There's two problems: a) cloud.cfg doesn't list the growpart module -> https://bugzilla.redhat.com/show_bug.cgi?id=966888 b) cloud-init can't find a resizer, since F19 parted doesn't seem to support online partition resizing (option 'resizepart' is not available). The work-around for this is to install cloud-utils.
3) Can we please make the default user more provider agnostic? Pretty please?? I propose to follow Debian and Ubuntu and use 'fedora' as the default user.
4) The kickstart file is stored in /root. That should probably be purged.
5) The console log is empty. Can we add 'console=ttyS0' to the kernel commandline?
6) cloud-init doesn't display the networking info correctly -> https://bugzilla.redhat.com/show_bug.cgi?id=949832
...Juerg
We have a couple of known issues in this beta release, which will probably cause us to respin some intermediate updated images between beta and final.
- Cloud init hostname module broken
- This causes an about-one-minute delay on boot, during which ec2-user is not created.
Bug https://bugzilla.redhat.com/show_bug.cgi?id=964006
- Growroot support not working right
possibly related to the above? Definitely related to recent conversation.
Currently still producing 10GB images until this is resolved
No bug yet but will file something soon.
- qcow2 image is uncompressed
this is due to the current release engineering workflow
will be fixed one way or another for general release
-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mattdm@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
On Fri, May 24, 2013 at 10:47:25AM +0200, Juerg Haefliger wrote:
- The hostname is not set correctly. See my updates to
https://bugzilla.redhat.com/show_bug.cgi?id=964006. Looks to me like a systemd/selinux issue.
Ahaha!
I had ruled that out because I booted with selinux=0 and it didn't work either.
But apparently, cloud-init completely fails in that situation too.
So, I changed to writing "SELINUX=permissive" to /etc/sysconfig/selinux, and that didn't work either, but on further inspection, on boot SELinux is still in enforcing mode, ignoring that config file. (Changed it to "SELINUX=disabled" doesn't work either.)
Sooo, I booted with enforcing=0 on the kernel command line, and now it works.
I think maybe I need a vacation. :)
Are the sysconfig options not working for other people?
(I think probably `Requires systemd-hostnamed.service` in the systemd config is a good idea too.)
- The root partition is not resized. There's two problems: a) cloud.cfg doesn't list the growpart module ->
https://bugzilla.redhat.com/show_bug.cgi?id=966888 b) cloud-init can't find a resizer, since F19 parted doesn't seem to support online partition resizing (option 'resizepart' is not available). The work-around for this is to install cloud-utils.
cloud-utils brings in a lot of dependenies. Including, apparently, glusterfs and ceph. Do you think it's possible/useful to split out growpart?
It looks like the resizepart command isn't upstream (even in the
- Can we please make the default user more provider agnostic? Pretty
please?? I propose to follow Debian and Ubuntu and use 'fedora' as the default user.
Yeah. I just want consensus on this. Let's start a new thread discussing it.
(One particular question is whether we want to use ec2-user in EC2, or the generic one.) Also, the livecd uses "liveuser". Maybe we should use "clouduser"?
- The kickstart file is stored in /root. That should probably be purged.
Sure. It's pretty standard to have it there, but we can save 6K and people can look for it on the web. :)
- The console log is empty. Can we add 'console=ttyS0' to the kernel
commandline?
Sorry, yeah. I meant to do that before.
- cloud-init doesn't display the networking info correctly ->
*nod* Yeah, I've known about that. Thanks for filing the bug.
On Fri, May 24, 2013 at 3:33 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, May 24, 2013 at 10:47:25AM +0200, Juerg Haefliger wrote:
- The hostname is not set correctly. See my updates to
https://bugzilla.redhat.com/show_bug.cgi?id=964006. Looks to me like a systemd/selinux issue.
Ahaha!
I had ruled that out because I booted with selinux=0 and it didn't work either.
But apparently, cloud-init completely fails in that situation too.
So, I changed to writing "SELINUX=permissive" to /etc/sysconfig/selinux, and that didn't work either, but on further inspection, on boot SELinux is still in enforcing mode, ignoring that config file. (Changed it to "SELINUX=disabled" doesn't work either.)
Sooo, I booted with enforcing=0 on the kernel command line, and now it works.
I think maybe I need a vacation. :)
Are the sysconfig options not working for other people?
Dunno. I modified /etc/selinux/config directly.
(I think probably `Requires systemd-hostnamed.service` in the systemd config is a good idea too.)
- The root partition is not resized. There's two problems: a) cloud.cfg doesn't list the growpart module ->
https://bugzilla.redhat.com/show_bug.cgi?id=966888 b) cloud-init can't find a resizer, since F19 parted doesn't seem to support online partition resizing (option 'resizepart' is not available). The work-around for this is to install cloud-utils.
cloud-utils brings in a lot of dependenies. Including, apparently, glusterfs and ceph. Do you think it's possible/useful to split out growpart?
Agreed, it brings in a whole bunch of useless stuff. I'd rather have resizepart in parted (thank for the bug report btw) and drop cloud-utils than pull stuff out of cloud-utils. Seems like a lot of effort for little (temporary) benefit.
It looks like the resizepart command isn't upstream (even in the
- Can we please make the default user more provider agnostic? Pretty
please?? I propose to follow Debian and Ubuntu and use 'fedora' as the default user.
Yeah. I just want consensus on this. Let's start a new thread discussing it.
Will do.
(One particular question is whether we want to use ec2-user in EC2, or the generic one.) Also, the livecd uses "liveuser". Maybe we should use "clouduser"?
- The kickstart file is stored in /root. That should probably be purged.
Sure. It's pretty standard to have it there, but we can save 6K and people can look for it on the web. :)
Ok. I guess we can leave it there if there's some benefit to it. I just thought it was noise that nobody cares about.
- The console log is empty. Can we add 'console=ttyS0' to the kernel
commandline?
Sorry, yeah. I meant to do that before.
- cloud-init doesn't display the networking info correctly ->
*nod* Yeah, I've known about that. Thanks for filing the bug.
-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mattdm@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
On Fri, May 24, 2013 at 04:20:03PM +0200, Juerg Haefliger wrote:
- The kickstart file is stored in /root. That should probably be purged.
Sure. It's pretty standard to have it there, but we can save 6K and people can look for it on the web. :)
Ok. I guess we can leave it there if there's some benefit to it. I just thought it was noise that nobody cares about.
I think it's useful to know how _this_ image was built. I occasionally find myself caring. :)
-
Juerg Haefliger -
Matthew Miller