I have been running Rawhide and more recently the Fedora 15 development branch for quite sometime and recently noticed that the mute button works!   Apparently a kernel update fixes this problem due to a series of patches merged upstream.    I have no more hardware issues to complain about.  Muted

$ cat /etc/sysconfig/network-scripts/ifcfg-eth0

# Intel Corporation 82567LM Gigabit Network Connection
DEVICE=eth0
HWADDR=00:23:2A:F7:CB:F6

(values changed to protect the innocent)

The hardware MAC address is used by udev to rename the devices when necessary to preserve consistency and udev uses the file /etc/udev/rules.d/70-persistent-net.rules to accomplish this.   The relevant line on my system looks like

# PCI device 0×8086:0x10f5 (e1000e)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:23:2A:F7:CB:F6″, ATTR{dev_id}==”0×0″, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth0″

According to the feature description,  this is racy and error prone and we have now a alternative method that picks up names using the BIOS with a udev helper to accomplish the same task in a better way.    Quoting from the description:

“Starting in Fedora 15, Ethernet ports on servers will have a new naming scheme corresponding to physical locations, rather than ethX. Ethernet ports embedded on server motherboards will be named em<port_number>, while ports on PCI cards will be named pci<slot_number>#<port_number>, corresponding to the chassis labels. Additionally, if the network device is an SR-IOV Virtual Function, the name will have a suffix of _<virtual_instance>.

By changing the naming convention, system administrators will no longer have to guess at the ethX to physical port mapping, or invoke workarounds on each system to rename them into some “sane” order.”

Similar to the Btrfs effort in Fedora, this has also been a project involving many people over the last several years.    Again, let’s look at the overall timeline:

*  Matt Domsch from Dell announces a project called biosdevname back in August 2007. biosdevname review request filed for Fedora soon after.   He worked with Harald Hoyer (Red Hat udev maintainer) and Kay Sievers (Novell and upstream udev developer) via this review request to enhance software and fix bugs.   biosdevname becomes part of Fedora 8 and things went fairly quiet in Fedora land although work continued elsewhere

* After consensus is reached,  we had a quick announcement that this feature was coming up as part of the Fedora 15 discussions.    This was followed up at a later point with more details as a new version of biosdevname hit rawhide.    The rules are getting into upstream udev.   Anaconda,  kickstart and dracut is getting enhanced to use biosdevname and it will also be installed by default in the Fedora 15 release.

Anaconda will use this feature by default and so far there isn’t a way to disable it during a fresh installation.   Upgrades will preserve the same behaviour as before since /etc/udev/rules.d/70-persistent-net.rules will retain the names.   As indicated earlier,  this is of interest to system administrators managing server class hardware.  Systems which feature a SMBIOS 2.6 version or above and have multiple ethernet ports will notice a difference in the network device names on a fresh installation to provide consistent names matching how the network ports are physically located.

Welcome to a new era.  After 18+ years of history in Linux of having ethX as device names for ethernet ports and we are seeing a change now.  We lived through a change of /dev/hd* to /dev/sd* and we can deal with this as well as the benefits are going to be good for system administrators and desktop users and others are not affected typically. Kudos to the developers involved in this effort. A persistent effort to bring persistent device names is finally paying off.

*  Eric Sandeen,  Ext4 developer upstream and for Red Hat submitted a patch to Anaconda in January 2009 that allows users to use Btrfs as one of the filesystems and format their partitions with the installer if you explicitly pass a option “icantbelieveitsnotbtr” .  It was documented and announced in Fedora 11 Alpha release.  Just in case,  this is not obvious,  it was a bit of a joke but served the purpose of making it harder to actually pick this option and conveyed to the users this wasn’t a serious choice yet.   It was definitely and clearly a experimental option

* In Fedora 13,  the next step was taken with a integration of a yum plugin that supports Btfs snapshotting feature.  Everytime you install or remove packages, this plugin will take a snapshot and allows you to rollback and restore from any software changes.   yum history undo does a pretty good job in many cases but filesystem level undo is quite useful too.   You only had to pass “btrfs” as a installation option in this release but it was still considered experimental

* In Fedora 15, you don’t need to pass any option.  Btrfs will be one of the options by default but do note that Live images don’t support anything other than the default of Ext4 still.

The future plan for Btrfs in Fedora  has been detailed out by Josef Basik,  Red Hat Btrfs filesystem developer.  Josef is planning on adding Btrfs support into GRUB 2 as well but Grub 0.97, the legacy version is what Fedora is using by default and although the repository does have a grub2 package for users wanting to try it out,  more work needs to be driven by someone interested in this effort in Fedora to make GRUB 2 the default.   Fedora 17 or later would have this filesystem by default if things go according to plan but I fully intend to migrate to Btrfs as my root filesystem for Fedora 15 if it finally gets a fsck that can actually repair damage instead of just reporting it which is indeed part of the Fedora plan.    One of the interesting projects to keep an eye on is snap,  a project to provide desktop integration of Btrfs and I would really love to see seamless integration with file managers like Nautilus.     The future is butter and it is better.

kernel-2.6.34-38.fc14
---------------------
* Tue Jun 15 2010 Kyle McMartin <kyle@redhat.com> 2.6.34-38
- Fix build by nuking superfluous "%{expand" which was missing a
  trailing '}'. You may now reward me with an array of alcoholic
  beverages, I so richly deserve for spending roughly a full
  day staring at the diff of the spec.

Back to business then. FESCo approved three more features yesterday. Let’s take a look at them.

Upstarting upstart

One of the features that I am most excited about for Fedora 14 is systemd. If you have been living under a rock and haven’t heard about systemd yet, you can read Lennart’s late night novel . When you finish reading all of that,  you will have a very through understanding of systemd and you will be only be a couple of years older.  LWN has a nice and much smaller article about it as well.   I worked with Lennart on writing up a feature proposal and also packaged it up for Rawhide.   It is in the development repository already.

# yum install systemd

Boot with selinux=0 init=/bin/systemd and you can see it in action.  Note however that much of the work is still to be done.   Once we get the selinux policy updated,  we will obsolete upstart and make systemd the default init system for Rawhide soon.   Whether it will be the default for Fedora 14 will have to be decided based on testing and feedback before the feature freeze.   Systemd is a drop in replacement because it is compatible with sysv init scripts and this transition is  easier as a result.   Replacing the init system is grand and bold endeavour and Fedora 14 will hopefully take the first step.

MeeGo  -  Let’s go

MeeGo is a merger of Maemo and Moblin to create a new operating system for netbooks.  Fedora 13 had a moblin spin and since Moblin itself was a RPM based distribution,  Peter Robinson, a community volunteer in Fedora was able to collaborate very effectively together with the Moblin project and pull in the new user interface.  One of the benefits of the merger is that much of Moblin stack and the RPM base remains the same and Peter Robinson is taking the effort to provide the MeeGo user interface within Fedora.  Fedora 14 will have a exicting new netbook interface.

How sweet!

OLPC with it’s XO laptop is the largest vehicle for Fedora deployments and around two million Fedora systems are out there, all over the world running Fedora with a custom kernel on the XO laptops.  The latest revision even includes GNOME and a easy way to switch to it but the default interface is Sugar which was developed in collaboration and funded by Red Hat initially and now managed by the non-profit foundation called Sugar Labs.

Sebastian Dziallas , a community volunteer for Fedora has been busy for a long time packaging and integrating the Sugar interface and it’s many add-ons for Fedora as well as leading an effort called Sugar on a Stick aka Soas which is in Fedora 13, an official Fedora spin.  He and Peter Robinson are now working on updating the sugar interface to the latest revision, 0.90 in Fedora and Soas will feature it too.

What would you like me to cover next?  Let me know your feedback and questions.

More content in live images

LZMA/Xz is a relatively new and better method for compression and Fedora has increasingly been taking advantage of it.   Fedora switched over from gzip to using LZMA for the RPM payload back in Fedora 12.  Fedora 14 will combined the previous feature with the next step of better compression in the live image itself.  The smaller size enables us to store more content in the same size.   Bruno Wolff III, a community contributor took over from me as the games spin maintainer after the Fedora 10 release and has been very actively working on forming a good gaming community in Fedora and also improving livecd-creator to work with larger images.  Games are often the biggest size packages we have in the Fedora repository and switching to using LZMA in livecd-creator is of obvious benefit not just to the games spin but all live images we include as part of a Fedora release including half a dozen Fedora spins and many remixes and custom images that end up getting generated via livecd-tools.  This is expected to reduce the image sizes by 10%.  Quite a handy win if we get all the pieces ready in time.   We could include more packages in the live images and since newer versions of software often tend to be bigger, this is a very welcome improvement.

Much faster porn picture browsing

Fedora is replacing the old and stagnant libjpeg library with libjpeg-turbo library by default.  It contains numerous performance related enhancements and is at least twice faster in JPEG compression/decompression than original libjpeg on platforms with MMX/SSE instruction set. It has same API/ABI like original libjpeg and also runs on non-SSE platforms where is around 25% faster.  Adam Tkac, from Red Hat is leading the fork effort as part of his involvement in the TigerVNC. As you might recall, Fedora switched over to using TigerVNC for Fedora 11 and this is a logical next step.    Instead of multiple software components bundling patched versions of a library,  Fedora will have a better maintained and faster equivalent.   The spells W-I-N to me.  libjpeg-turbo is currently in the Fedora package review queue and looking for a reviewer.   Hopefully someone volunteers to do that and we will see it in Rawhide soon.

Multi-path device support including bootup

If you have installed Fedora 13,  you certainly noticed a new screen for selecting storage devices.  Anaconda, the Fedora installer has been revamping the storage handling for the last several releases and Fedora 14 will add another tab if you select “Specialized Storage Devices”.  Multi-path is really an enterprise feature that adds some redundancy and useful if you have large storage and don’t want to have a single point of failure if your switch or cable connection goes down.   Additionally,  Fedora will have support for booting from a multi-path device as well. Peter Jones from Red Hat is leading this effort.

This is just the beginning as FESCo will have weekly meetings throughout the development cycle until the feature freeze currently scheduled for July 9th 2010.   Fedora has a open and transparent process for proposing and approval of features and the policy is detailed here.  The technical aspects of Fedora is led by the Fedora Engineering Steering Committee aka FESCo.  FESCo is a community elected body and gathers on a weekly basis to discuss several technical issues and approval of features that are part of a new release is one of the recurrent agendas.    We can expect to see many more features proposed and approved before the feature freeze.  I am excited and curious to know how the final feature list will look like.

My next blog post would cover the newly approved features of Fedora 14 in detail.  Along the lines, we will also take a look at how the whole process works and what is involved in getting a feature into the official feature list.   Let’s get the ball rolling soon.