Korora 19 (Bruce) beta is out

The first beta release of version 19 (codename “Bruce”) is now available for download.

As I have been thoroughly tied up with full-time work and University, this release is pretty much the sole work of my fellow Korora developer and right-hand man, Ian “firnsy” Firns. A HUGE thanks to him for all his hard work in getting this release up and out, it wouldn’t have been possible otherwise!

This is the first beta release of Korora which is derived from a beta release of Fedora1 (previous beta versions of Korora were from a stable upstream release) and as such there will likely be a larger number of bugs and many software updates.

See Korora Project website for more details.

1 Korora is not provided or supported by the Fedora Project. Official, unmodified Fedora software is available through the Fedora Project website.


Update: the latest versions of Fedora now support the discard option in crypttab, not allow-discards.

I have an (unfortunately too small) Samsung 840 Pro in my laptop and it’s been a long time since I’ve re-installed (no time for Korora for months) and I’ve noticed it getting a little sluggish. Most noticeable is long pauses while the drive goes nuts. I figured it was probably time to get some TRIM action on the drive, something I never bothered with before because I didn’t really care.

My setup is reasonably common, I imagine. I have a regular old boot partition and a second encrypted partition which is used as a physical volume for lvm. Hence any and all lv are automatically encrypted. If you’re using encryption, it’s possible that enabling trim could give an attacker insight into what blocks have/haven’t been used, but for me it’s just to make it harder for someone to get my data if I lose the laptop or it’s stolen.

First things first, the file system needs to support trim (ext4 does). If you’re using Fedora 18 you may have to edit your /etc/fstab and add the discard mount option to any partition you want to trim.
/dev/sda1 /boot ext4 defaults,discard 1 2

Under Fedora 19, my non-encrypted, non-lvm /boot partition works with fstrim out of the box (I didn’t have to set the discard mount option), so that’s good.

chris@localhost ~ $ sudo fstrim -v /boot
[sudo] password for chris:
/boot: 407 MiB (426762240 bytes) trimmed

With my / and /home partitions however it’s a different story, I get this:
chris@localhost ~ $ sudo fstrim -v /home
fstrim: /home: FITRIM ioctl failed: Operation not supported

So, problem is that somewhere along the way the discard commands aren’t reaching the device.

I have filesystem, lvm, luks, block layers I guess and I know it’s not the first or the last, so that leaves lvm and luks. Thanks to this post, it was pretty easy to enable on the latter two.

I edited the /etc/lvm/lvm.conf file and enabled the issue_discards option:
issue_discards = 1

Now to ensure that discards are sent to my crypto layer by adding the allow-discards option to /etc/crypttab
luks-blah-blah-blah UUID=blah-blah-blah none allow-discards

Note: Thanks to chesty for pointing out that on Debian and other distros the format of that file and discards option may be different. Check man crypttab for the right option, but it may be something like this:
luks-blah-blah-blah UUID=blah-blah-blah none luks,discard

OK, so config files are in place, no as both of these configs are included in the initramfs, time to rebuild it:
chris@localhost ~ $ sudo dracut --force

Note: For Fedora 18 I had to tell dracut to include the crypttab file, as per this bug report.
chris@localhost ~ $ sudo dracut --force -I /etc/crypttab

Note2: Again, on Debian updating initramfs is different, try the update-initramfs command.

You can confirm that crypttab is in the initramfs with:
chris@localhost ~ $ sudo lsinitrd |grep crypttab

After a reboot, I can test out fstrim again, which now works! (By the way, it’s fast.)
chris@localhost ~ $ time sudo fstrim -v /home
/home: 332.6 MiB (348778496 bytes) trimmed
real 0m0.194s
user 0m0.007s
sys 0m0.015s

Cron it
Finally, set this as an hourly cron job and enjoy the benefits.
root@localhost ~ # echo -e "fstrim /\nfstrim /home\nfstrim /boot" > /etc/cron.hourly/fstrim

rsync and a Nexus device

Nexus devices use media transfer protocol to transfer files to and from the device. There is no removable storage so you can’t take the card out and copy files from it via a card reader.

In the past I’ve used adb tools to push and pull to my device over USB debugging, however while we wait for nautilus gvfs support to be more reliable, this is what I do now (found online somewhere).

Unplug Nexus device.
sudo dnf -y install fuse fuse-libs libmtp simple-mtpfs
sudo wget http://christophersmart.com/files/99-nexus.rules \
-O /etc/udev/rules.d/99-nexus.rules
sudo udevadm control --reload-rules

Plug in device and look for mtp device.
ls -l /dev/libmtp*
mkdir ~/nexus
simple-mtpfs ~/nexus && ls -l ~/nexus

Now rsync to your heart’s content
rsync -Pa ~/nexus/DCIM/ ~/Photos/nexus/

To unmount.
fusermount -u ~/nexus

Korora 18 released, and it’s the same as the beta

We have decided to make the existing beta release of Korora (Flo) 18 the final version, as the beta period did not reveal any major issues which warranted a new build. The existing beta images have simply been renamed, so if you already have the beta you also have the final release.

We would like to thank everyone who has tested the beta and provided feedback, and welcome everyone to download it and try too!

Known issues


Derived from Fedora 181, this release comes with the usual Korora extras out of the box, such as:

  • Adobe Flash plugin
  • Experimental support for Valve’s Steam client
  • unburden-home-dir, which moves cache files (like in Firefox profiles) onto RAMFS at login
  • undistract-me, which pops up a GUI notification when a terminal command has completed
  • Tweaked KDE and GNOME base systems
  • Experimental support for Cinnamon desktop in GNOME
  • Third party repositories (Chrome, RPMFusion, VirtualBox)
  • Firefox as the default web browser (with integration theme for KDE)
  • Firefox extensions enabled (Adblock Plus, DownThemAll, Flashblock, Xclear)
  • Instant messaging client (Kopete for KDE, Empathy for GNOME)
  • Microblogging client (Choqok for KDE, Gwibber for GNOME)
  • Full multimedia support (excluding Flash, see next)
  • Jockey device manager to handle drivers such as ATI and NVIDIA
  • Video editor (Kdenlive for KDE, OpenShot for GNOME)
  • VLC as the default media player
  • SELinux enabled (particularly worthwhile for Flash)
  • and more..


It is now possible to upgrade from Kororaa 17 to Korora 18, thanks to Fedora’s FedUp tool. Should you encounter issues, please perform a fresh install. Users still on Kororaa 16 should install 18 as the older version is no longer supported upstream and you are not able to update to 18 directly as 16 does not include the FedUp tool.


We’d love to hear your feedback, so download it today and let us know!

1 Korora is not provided or supported by the Fedora Project. Official, unmodified Fedora software is available through the Fedora Project website.

The new Anaconda installer

It’s no secret that the new Anaconda installer for Fedora 18 has caused a stir. As part of a major internal re-write, the user interface has been completely re-designed which has caused some confusion and there are bugs and missing features. This is why we included an install video in Korora 18, to help walk you through the process.

However, like all good free and open source software, while this might be the case now it will just keep getting better (especially if users report their problems and post ideas on Bugzilla). Fedora 18 was so delayed that the community didn’t have a chance to address all issues in the interface, unfortunately. Some of the badness has already been fixed for the next release however, with more improvements to come.

So, yes, it might be hard to use for this release but it’s getting better. And thankfully it’s just the installer and not the rest of the interface, so it’s a one-off pain, not an every day one. If it’s really a drama, one could install version 17 and use FedUp to upgrade without using the new installer.

Finally, Anaconda developer Will Woods an excellent blog post on the re-write, which really opens your eyes to the need for it (it’s much, much more than just the user interface).

Here’s some of the content:

Why rewrite, anyway?
Back in August 2009 we were trying to redesign the storage UI to handle modern storage needs. This turned out to require rewriting a lot of the storage back-end code (again) because the existing anaconda code was basically all duct tape and bubble gum, creaking under the strain of modern demands.

You might think I’m exaggerating, but keep in mind that anaconda was originally written in 1999, for Red Hat Linux 6.1, It was designed to run off a 1.44MB floppy, using the still-newish Linux 2.2.x kernel.

In 2009 it still had its own custom initrd init system – called “loader” – written entirely in C. (Statically-linked, too, until 2007.) So anaconda had its own copy of stuff like mount(), and losetup, and mknod.. but no bash before the GUI started. (Good luck trying to debug anything!)

The design pre-dated udev and /sys – and devfs, HAL, and NetworkManager, and dbus – and had its own builtin module loading stuff instead of depmod and modprobe. So anaconda was doing all the hardware setup (probing, module loading and unloading, network setup, disk setup, RAID setup, etc., etc.) by itself… and not always doing it well. And every time there was a new device driver for anything we had to manually add support for it to the installer.

And specifically on the user interface:

And then there’s the GUI. It was single-threaded, so (for example) while we waited for lvm or yum to do something the UI would just.. stop drawing. If you dragged a window around you just ended up with big empty gray blotches until lvm finished and let us start refreshing the UI again.

It was also designed for much smaller screens – 640×480, or 800×600 if you were lucky. You can’t fit much on a screen that size (smaller than your average smartphone!), so it made sense to break the process into a series of steps. Except by 2009 you ended up with screens that looked like this [when setting the root password]:

root password
Great use of space there!

The logic for moving between steps had also gotten really hairy and fragile. Like, as soon as you finished partitioning the disk (but before you picked software to install!) we formatted the disks, because we used to need swap space to even think about running yum. But then what happens if it turns out you need more hard drive space to install the stuff you want? TOO BAD, YOU CAN’T GO BACK NOW!

So on behalf of Korora Project please forgive us for causing you frustration, but we’re here to help and believe us when we say it is already improving!

Bug: Korora 18 KDE installer sometimes not loading

Update: Try running the installer from the command line with two commands, like so:
xhost +

A couple of users have reported that running the installer under the KDE live image does not do any thing, i.e. the loading cursor appears run but no program loads. This does not appear to affect GNOME.

If you run it from the terminal you get a error about X and GTK.

[liveuser@localhost ~]$ liveinst
No protocol specified
xhost: unable to open display ":0"
Starting installer, one moment...
anaconda 18.37.11 for Fedora 18 started.
No protocol specified
** (anaconda:1940): WARNING **: Could not open X display
No protocol specified
Traceback (most recent call last):
File "/sbin/anaconda", line 923, in
setupDisplay(anaconda, opts)
File "/sbin/anaconda", line 585, in setupDisplay
File "/usr/lib64/python2.7/site-packages/pyanaconda/__init__.py", line 213, in initInterface
from pyanaconda.ui.gui import GraphicalUserInterface
File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/__init__.py", line 22, in
import meh.ui.gui
File "/usr/lib/python2.7/site-packages/meh/ui/gui.py", line 23, in
from gi.repository import Gtk
File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 76, in load_module
File "/usr/lib64/python2.7/site-packages/gi/module.py", line 244, in _load
overrides_modules = __import__('gi.overrides', fromlist=[self._namespace])
File "/usr/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line 1624, in
raise RuntimeError("Gtk couldn't be initialized")
RuntimeError: Gtk couldn't be initialized

We think this might be this upstream bug, however nothing concrete has been discovered.

Please try booting again after a power-cycle with your network cable either plugged in or out, the opposite of what it was when it wasn’t working. Please let us know how you go with this, especially if anyone finds something repeatable.

Update: Try running the installer from the command line with two commands, like so:
xhost +

Korora 18 (Flo) beta released

NOTE: Kororaa Linux has changed to the Korora Project and moved to a new website at http://kororaproject.org.

The Korora Project is pleased to announce the first beta release of version 18 (codename “Flo”) which is now available for download.

Derived from Fedora 181 stable, this release comes with the usual Korora extras out of the box, but now also includes:

  • Adobe Flash plugin
  • Experimental support for Valve’s Steam client
  • unburden-home-dir, which moves cache files (like in Firefox profiles) onto RAMFS at login
  • undistract-me, which pops up a GUI notification when a terminal command has completed

It is now possible to upgrade from Kororaa 17 to Korora 18, thanks to Fedora’s FedUp tool.

This is a beta and we’d love to hear about your experience so that we can make it better! Please send us feedback in the forums or log a bug report if you have any issues. Of course you can find us on social media like Identi.ca, Twitter, Google+ and Facebook.

1 Korora is not provided or supported by the Fedora Project. Official, unmodified Fedora software is available through the Fedora Project website.

Introducing the Korora Project

It’s with great pleasure that I announce that Kororaa Linux is changing to the Korora Project. We haven’t just been super busy working on the new 18 release, but also setting up this new project and everything that goes with that!

The motivation for this was not only the dropping of an excess letter ‘a’, but it’s also a reflection of the community which is starting to grow nicely and I wanted something people could better associate with and belong to.

The new website has been set up at http://kororaproject.org and feedback is welcome (although be gentle, we’re still ironing out any kinks). All future news will be posted to that site, however the current http://kororaa.org domain will stay live for the foreseeable future also.

The forum has been migrated to the site and existing users will need to change their passwords.

Finally, I must send out a massive thank you to Ian (firnsy) Firns, who has done an amazing job not only with the new site and content but also helping to build the 18 release, including our new build system which makes life so much easier. Without him, this simply would not have been possible and as such he has become the first official Korora co-developer. Thanks firnsy!

P.S. The new Korora 18 images really are just around the corner, we’ve delayed to add some exciting new features such as out of the box support for Adobe Flash and inclusion of Valve’s Steam client. Stay tuned (on kororaproject.org)!

Capturing a network stream with VLC

AC has a nice post about capturing a network stream with VLC.

Work around NVIDIA blue screen bug, by downgrading version (Update: fixed NVIDIA version released)

Update: New version 304.32 has been released which apparently fixes this issue, so this is no-longer neccessary. If you have already done this to get a working system and locked the version, remove then and update.
sudo vim /etc/yum/pluginconf.d/versionlock.list && sudo yum clean all && sudo yum update

Thanks to zektor in the Kororaa forums for posting this fix. It is reported on RPMFusion’s Bugzilla and nvnews.net.

The 300.x.x series NVIDIA driver (currently beta) has a bug which causes some newer GPUs to have a blue tinge on the screen. In Kororaa, Jockey installs this latest version.

If your card is supported by the previous version, you can downgrade to this to solve the problem, then lock yum so that it doesn’t upgrade to 300.x.x series.

Remove existing:

sudo yum erase *\nvidia\*

Downgrade version:
sudo yum install akmod-nvidia-295.53-1.fc17.1 \
xorg-x11-drv-nvidia-libs-295.53-\*.{x86_64,i686} \
xorg-x11-drv-nvidia-295.53-1.fc17 \
nvidia-settings-1.0-18.fc17 \

Lock version:
sudo yum install yum-versionlock
sudo yum versionlock akmod-nvidia-295.53-1.fc17.1 \
xorg-x11-drv-nvidia-libs-295.53-\*.{x86_64,i686} \
xorg-x11-drv-nvidia-295.53-1.fc17 \
nvidia-settings-1.0-18.fc17 \

Now you can reboot your machine.