What functionality is expected for anaconda's Device Type LVM Thin Provisioning? Right now when I choose this device type for, e.g. home, I still can't choose a Desired Capacity that's larger than free space in the VG. Ergo, I can't create a virtual size LV. Is this expected? And is the main idea in this roll out just to support the better faster thinp snapshots? Or am I missing something?
Like I did on the 14th on the linux-bcache list I'd like to send an
update on the progress of bcache related packages. While focussing on
Fedora packaging of bcache-tools, I had some good collaboration with
other packagers resulting in improved bcache support in other packages
as well. Other Linux distro's may benefit from these updated packages too.
On 27th of September util-linux v2.24 RC will probably be released. This
release supports the identification of bcache superblocks in libblkid,
actually integrating and obsoleting probe-bcache. Because of this udev
rules for bcache can be simplified because they only need blkid. Of
course this only applies to systems where util-linux v2.24 RC (or
higher) actually is installed, otherwise probe-bcache is still needed.
Since version 032 Dracut already had bcache support. Since version 033
it adds support for util-linux v2.24 RC, so even without (obsoleted)
probe-bcache it is able to identify bcache using blkid. Additionally
Dracut benefits from blkid being able to identify bcache, because it
uses blkid to identify all necessary kernel modules automatically, so no
-N option is needed anymore.
With the release of v2_01_102 LVM2 now accepts Physical Volumes on
bcache by default. This simplifies the creation of initramfs (by Dracut)
because no specific LVM2 option (--lvmconf) needs to be passed to
Dracut.For the user this means that updating a kernel just works out of
The bcache-tools package is available in Fedora 20. I plan to build an
updated package that no longer includes probe-bcache when the new
util-linux is released.
Anaconda (the Fedora installer) does not support bcache yet. This is
planned for Fedora 20. This is important when installing Fedora on a
system and having your root filesystem on bcache. Althought other
Distro's don't use Anaconda, I guess their installers also need to be
changed in some way to supportbcache.
Currently having Fedora installed with your root Filesystem on bcache is
possible, but It's done in a fewsteps:
1. Install Fedora using Anaconda without using bcache, but create an
extra partition to supportan alternate root FS
2. From the running system build a bcache device using the extra
partition. Copy the current root FS to the bcache root FS
3. Reboot your system in the bcache root FS, and reclaim the spaces used
by the non-bcache root partition
More information can be found below, related to the "SSD Cache Fedora
The SSD Cache Fedora test day
On 13th of October there's an "SSD Cache Fedora test day": see the Wiki
page https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache. This
page is work in progress, any feedback is welcome. People interested in
testing are invited to participate on 13th of October.
When there's anything new toreport, I'll keep you posted.
In FESCo ticket #1115, it was decided to modify the privilege escalation
policy in order to allow local, active, admin user to update/remove/etc
signed software without requiring a password.
At this point, such an user can do "pkcon install <package>" to install
packages without being prompted for the password.
In FESCo ticket #1117, it was decided to extend this policy to
potentially cover other privileged operations. At this point, "we" are
looking for more use cases. Lot of such use cases are already listed on
the following page,
Here is a sample use case; ability to launch my own VMs using
virt-manager without authenticating every time.
Do *you* have a use case of your own? Here is your chance to get rid of
those password prompts for your own use case!
Please *note* that these policies can be modified locally (or disabled
altogether) to fit different situations. An option to *specifically*
enable or disable such privilege escalation policy can be given at the
install time or / and run-time. Thoughts?
Also *note* that the goal of this email (and the ticket in general) is
to promote brainstorming at this point. I'm not saying or promising that
"we" are going to do everything you guys demand.
Some of you may find http://tinyurl.com/linus-printer to be relevant
In GNOME Software, we show a list of applications for each category
that we think are frikin’ awesome. Some have AppData, and some
don’t. For the ones that don’t yet have AppData it leaves the
responsibility of writing the long description to the Linux community,
where we can push the data back to upstream so that all the
distributions can benefit. So far we’ve had a superb reaction from
lots of upstream projects and a lot of descriptions have been merged.
For Fedora 20 we want all the awesome apps to have AppData, so users
can evaluate the application before installing it. It would add a
really nice bit of polish to the whole experience. If you can spare 5
minutes and want to help.
I’ve got another shared document that just needs a few details for
The list of awesome-but-unloved apps is: audacity, ardour2,
gnome-banshee, rosegarden, sound-juicer, doom, openarena, xonotic,
tremulous, btanks, frozen-bubble, quadrapassel, neverball, gnomine,
wesnoth, supertuxkart, redeclipse, lyx, gparted, virt-manager,
eclipse, gitg, monodevelop, blender, shotwell, octave, saoimage,
workrave, celestia, polari, pidgin, chromium, pitivi, vlc and
If you want to add any other apps there, please feel free, although I
would much prefer the AppData file to go upstream if you’re a
contributor or maintainer of a project. Remember, we can’t feature
applications on the front page that don’t have AppData, so that’s an
added incentive. I’d love to expose more people to blender for
There’s no way I can do all this myself for Fedora 20, so I really
need your help. Again. Thanks.
I've just submitted my first package review request to Fedora
(https://bugzilla.redhat.com/show_bug.cgi?id=1013363), which is for
"libre" (http://www.creytiv.com/re.html). This is a dependency for
"baresip" (http://www.creytiv.com/baresip.html), which is a barebones
SIP client that I've found very useful for testing SIP connectivity.
I would ultimately like to get baresip into Fedora, but I will first
need to get the libre and librem libraries packaged first.
I've done a lot of packaging in the past for personal and/or work
related projects, but this is my first time trying to share work with
the larger community.
Lars Kellogg-Stedman <lars(a)redhat.com>
Hi, checking whatrequires ffmpeg-libs and x264-libs, and can't install
on F20 vm is :
Sérgio M. B.
On 09/30/2013 03:20 AM, jonsmirl(a)gmail.com wrote:
> I didn't know about the command line option. This looks like the problem....
> Kernel command line: console=tty0 root=/dev/mmcblk0p3 ro rootwait
> loglevel=5 panic=10 console=ttyS0,115200 disp.screen0_output_mode=EDID:1280x720
> p60 hdmi.audio=EDID:0 sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 sunxi_fb_me
> m_reserve=20 sunxi_no_mali_mem_reserve
> Might make sense to set it so that mali/cedar can load. That way
> people will be able to work on them.
The idea is to give people the largest amount of free RAM possible in the default
config, this is esp. important for 256MB RAM boards. People who want to use cedar /
mali will need to do all kind of reconfiguration themselves anyways.
I'll add something about needing to tweak the kernelcmdline for this to the README.