I can't recall if we discussed this last time - but I suspect many folks
are going to be on vacation this and next Wednesday. Shall we cancel
those meetings and plan to re-adjourn on the 6th?
Joe Brockmeier | Community Team, OSAS
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
I wanted to give a heads up to the list that due to some personal stuff, I
will be taking a hiatus from my regularly scheduled activities. I'll still
be filing test results and sporadically responding to emails - but you won't
be likely to find me in our usual meetings and whatnot.
Rest assured, everything is fine and I will get back into things; I just
have to take care of some stuff.
On two UEFI systems, one with F23 Workstation, the other with F23
Cloud Atomic, I'm finding the grubx64.efi do not have the same hash,
even though rpm -q reports the same rpm installed on both. This is
Does the atomic tree include /boot/efi/EFI/fedora? And if not, is that
on the future feature list?
CVE-2015-8370 is what made me look at this. On BIOS computers, whether
conventional or atomic, GRUB2 user space tools are updated with
grub2-2.02-0.25.fc23, but that only updates user space tools. The user
has to manually run grub2-install to actually fix the problem. On UEFI
conventional installations, grubx64.efi is replaced automatically when
the RPM is updated; but apparently not on UEFI atomic installations.
Using grub2-install fails because grub2-efi-modules isn't installed by
default, and even if it were the resulting grubx64.efi is now no
longer signed by Fedora so it'll fail UEFI Secure Boot code signing
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2015-12-23 from 17:00:00 to 18:00:00 UTC
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Today in another conversation, I received this feedback about
Fedora cloud images. Not sure if there is bug open for this,
if not, do I file one?
+-- On Tue, 15 Dec 2015, Deepak C Shetty wrote --+
| How about having Fedora images that can be used out-of-the-box ?
| For eg: if we go to getfedora.org today, we have AMI, cloud images,
| but to really use these, u either need a AWS account or need to have
| a local cloud/openstack setup, otherwise (most typically) people
| fire up a VM using the cloud image it gets stuck at the cloud-init
| stage (thats where most of excitement of usign fedora goes down),
| then after waiting for several minutes when the cloud-init times
| out, it gives a login shell, where nothing works (which is expected
| bcos you are supposed to use this with pre-injected ssh keys) and
| then the end user just gets frustrated that he did everything he
| could, came so close to using a bleedign edge fedora. but still
| can't get into it.
| How about giving good documentation around hacking cloud images
| (using virt-* tools) to enable ssh passwd auth, enabling root/user
| login, so that its easy for newcomers to embrace cloud images
| Alternative could be to provide out-of-the-box working fedora
| images, which anyone can use to boot using virt-manager,
| virt-* utils or qemu cmdline and be able to login as root or
| non-root with sudo access, also image comes with decent enough
| root disk free space, so that embracing/trying out (which is
| the first time experience) becomes memorable than frustrating
| Thoughts ?
--- -P J P
Interesting tool. Hadn't seen it before.
I've also been working on a similar feature for the Atomic
image (although it should work just fine for the Base images
as well if we want). Basically, it adds a new boot menu item
labeled "Developer Mode" (working title ;) ).
It's meant for users with little experience (e.g. don't know
anything about cloud-init or how to use Vagrant, or even
Linux in general) or for those who want to "kick the tire",
so to speak.
When booted in Dev Mode:
- cloud-init is configured to set a password for the
cloud-user and root accounts
- tty1 is automatically logged in as root with a tmux
shell set up
- cockpit is automatically downloaded and started and
a URL is printed out for users to open in their
There is a card on the platinfra Trello board for this work:
One advantage of this approach is that everything necessary
is encapsulated in the image, so there are no pkg (or even
OS) requirements on the user env (other than being able to
boot the image). But it does require a small kickstart
tweak as well as a new package added.
Is there a wish list for things to consider adding to a future ISO?
These are things not on the current ISO that often are on other
baremetal installs like Workstation and Server products. I don't have
enough familiarity with whether these things should just be included
in the base installation and those that could be gathered in one or
more "util" or "extras" type of Fedora docker image. So far I'm
/lib/fimware/ is read-only so I can't add this:
[ 14.599501] iwlwifi 0000:02:00.0: request for firmware file
I don't know whether a /var/lib/firmware being bind mounted to
/lib/firmware can be done soon enough that it'll be picked up by the
pciutils, which contains lspci
These I have running in a fedora container. lspci mostly works, but
getting full -vvnn detail requires --privileged=true. And the other
three require it. iotop additionally needs --net=host. I'd be OK with
them just being available in a container, but it might make more sense
to just include them in the atomic ISO installation, maybe even
borrowing a list from the Server product?