Archive for the 'Fedora' Category

Page 2 of 11

Korora 20 (Peach) beta released

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

Note: This beta release of Korora is derived from a beta release of Fedora1 and as such there will likely be a larger number of bugs and many software updates.

For the first time we are introducing an Xfce desktop, which was made possible thanks to Maik Adamietz (AKA DarkEra) and others in the community. We would also like to thank Jeremiah Summers (AKA JMiahMan) for his assistance in updating the KDE version as well as Dan Marshall (AKA dan408) for his help with the MATE release. Thank you!

Features

GNOME 3.10

GNOME 3.10 will have a number of new applications and new features that will please GNOME-lovers. This release includes a new music application (gnome-music), a new maps application (gnome-maps), a revamp for the system status menu, and Zimbra support in Evolution. A preview of GNOME on Wayland compositor is also finally available. Refer to the GNOME 3.10 announcement for more details.

KDE Plasma Workspaces 4.11

A modern, stable desktop environment, this release includes faster Nepomuk indexing, improvements to Kontact, KScreen integration in KWin, Metalink/HTTP support for KGet, and much more. Refer to the KDE Plasma Workspaces 4.11 announcement for more details.

But wait, there’s more …

Derived from Fedora 201 beta, Korora benefits from Fedora’s long tradition of bringing the latest technologies to open source software users.

A complete list with details of each new inherited feature is available at the Fedora 20 Accepted Proposals List

  • Application Installer brings a new interface for installing packages in GNOME.
  • NetworkManager should be able to configure bond master and bridge interfaces with commonly used options and recognise their existing configuration on startup without disrupting their operation.
  • Ruby on Rails 4.0, which is the latest version of well know web framework written in Ruby.
  • LVM has introduced thin provisioning technology, which provides greatly improved snapshot functionality in addition to thin provisioning capability. This change will make it possible to configure thin provisioning during OS installation.
  • Plasma-nm replaces the current network applet in KDE with a new one and bring the latest features in NetworkManager to KDE.
  • SSD Cache is updated thanks to the recent kernel to support (fast) SSD caching of (slow) ordinary hard disks.
  • VirtManager user interface for managing virtual machines has the ability to easily manage snapshots.

Contributing

We don’t build Korora inside a box. We need your help! Bug reports are especially helpful – if you encounter any issues, please report them!

Korora is a fantastic, friendly community, and we have many ways in which you can contribute. 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.

What is the Beta release?

The Beta release is the last important milestone before the release of Korora 20. Join us in making this a solid release by downloading, testing, and providing your valuable feedback.

Of course, this is a beta release, meaning that some problems may still be lurking. A list of the problems already known can be found at the Common F20 bugs page.

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

Only use lua in %pretrans, not shell

In case I see an error like this again:
Error creating Live CD : Dependency check failed : (('package', '1.1', '1.fc20'), ('/bin/sh', ''), 0, 0, None)

Take a look at %pretrans in the spec file of said package.

We shouldn’t use shell in %pretrans as doing so breaks system installations and kickstarts because %pretrans is run before any dependencies are met.

This is spelled out in Fedora’s Packaging Guidelines.

If we must use %pretrans, we should do so using lua.

Korora 19.1 released

Yesterday we released Korora 19.1 which is a 3 month update to the original 19 release. Anyone already running Korora doesn’t need this, however if you are planning do any more installs we highly recommend downloading this new release as it includes all updates, a few tweaks and fixes a number of bugs. This release also includes versions of the MATE and Cinnamon desktops which we’ve created to gauge community interest.

The 19.1 release features:

  • All updates at time of release, including; KDE 4.11, kernel 3.11.2 and Firefox 24
  • Introduces support for MATE and Cinnamon desktops
  • Replaces rawtherapee raw image editor with darktable
  • Includes lzma compression, fonts-tweak-tool and gnome-documents
  • Fixes a systemd bug where the installer sometimes won’t start

MATE is a fork of GNOME 2, so if you’re pining for the old days and GNOME 3 isn’t your cup of tea, this may be for you.

Cinnamon is a fork of GNOME Shell and implements a more traditional layout with modern technology on top of GNOME 3.

MATE

korora-19.1-mate

CINNAMON

korora-19.1-cinnamon

Thank you to our community members who have helped to make this release possible.

Enjoy!

Fixing GNOME 3 freezes on SandyBridge and later Intel graphics

I had this problem in Korora/Fedora 19 and the fix appears to be enabling SNA (Sandybridge’s New Acceleration) acceleration for the card instead of the older UXA (Unified Acceleration Architecture).

It’s simple to do, just add the following contents to /etc/X11/xorg.conf.d/10-intel.conf file then restart X or reboot.
Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "AccelMethod" "sna"
EndSection

ZDNet on Korora 19, “If you make the effort to try it, you are likely to love it.”

After reviewing Fedora 19, J.A. Watson does a hands on with Korora 19.

Once installed, Korora has worked flawlessly for me. Every system, every bit of hardware, every driver — they have all worked straight out of the box. If you’re not into reading release announcements and such to find out what the differences [between Fedora and Korora] are, just install it and then browse around in the menus a bit. It includes a truly impressive array of pre-installed software, in every category. If you make the effort to try it, you are likely to love it.

Korora 19 (Bruce) released

Well, the cat’s out of the bag! Korora 19 (Bruce) is now available for download, which for the first time ever coincides with the same release of Fedora :-)

See the official Korora Release announcement for more details.

Why does yumdb include packages I haven’t explicitly installed?

Yesterday I posted how to list packages you’ve explicitly installed using yum, but some people have written in to say the command shows packages that they never explicitly installed. Some examples are, things like ModemManager and firmware packages.

I think the reason for this is that yumdb is including default and mandatory packages from when you install a group. I guess that makes sense, if you install a group then you’re telling it you want all of the packages there (but you shouldn’t get any deps).

For example, most systems probably have @hardware-support group installed, which is where ipw220-firmware comes from:
$ sudo yum groupinfo hardware-support |grep ipw2200
=ipw2200-firmware

Similarly, for ModemManager, it’ll be part of default @dial-up group.
$ sudo yum groupinfo dial-up |grep Modem
=ModemManager

So the only way around this I can see is to not install groups, because installing a group tells it to install whatever is in the list.

It would be great however, if yumdb supported a “group” type..

-c

How to list packages you have explicitly installed using yum

If you’re after a way to list all the packages you have explicitly installed (rather than packages that have been pulled in as a dependency) then you can do that with yumdb (thanks to Panu on #yum for the tip) which is powered by a new database added in 2009.

List packages you chose to install:
yumdb search reason user

List packages which were installed as deps:
yumdb search reason dep

Let’s go through an example, installing gnash which pulls in a few deps on my system:
Installed:
gnash.x86_64 1:0.8.10-8.fc19
 
Dependency Installed:
agg.x86_64 0:2.5-16.fc19 boost-iostreams.x86_64 0:1.53.0-6.fc19 boost-serialization.x86_64 0:1.53.0-6.fc19 gtkglext-libs.x86_64 0:1.2.0-18.fc18 pangox-compat.x86_64 0:0.0.2-2.fc19

As you can see, I got 5 dependencies, so let’s check whether yumdb got it right:
yumdb search reason dep |egrep "agg|boost-iostreams|boost-serialization|gtkglext-libs|pangox-compat"
 
agg-2.5-16.fc19.x86_64
boost-iostreams-1.53.0-6.fc19.x86_64
boost-serialization-1.53.0-6.fc19.x86_64
gtkglext-libs-1.2.0-18.fc18.x86_64
pangox-compat-0.0.2-2.fc19.x86_64

Yep, looks good. What about gnash?
yumdb search reason user |grep gnash
 
1:gnash-0.8.10-8.fc19.x86_64

Update:
Some people have written in to say the command shows packages that they never explicitly installed, things like ModemManager and firware packages.

I think the reason for this is that yumdb is including default and mandatory packages from when you install a group. I guess that makes sense, if you install a group then you’re telling it you want all of the packages there (but you shouldn’t get any deps).

For example, most systems probably have @hardware-support group installed, which is where ipw220-firmware comes from:
$ sudo yum groupinfo hardware-support |grep ipw2200
=ipw2200-firmware

Similarly, for ModemManager, it’ll be part of default @dial-up group.
$ sudo yum groupinfo dial-up |grep Modem
=ModemManager

So only way around this I can see is to not install groups, because installing a group tells it to install whatever is in the list.

It would be great if yumdb supported “group” type..

-c

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.

TRIM on LVM on LUKS on SSD

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.

Filesystem
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.

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

LUKS
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

Initramfs
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

Test
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