Although its still only beta, I was excited about a few significant changes in Fedora Core 17. I’ll explain.

Firstly, there is UsrMerge, which is explained in detail at http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge. I like the benefits of this, and it seems the best alternative to some other changes over time. Those changes:

Before UsrMerge, we had the following directories, among others :

/sbin/
/bin/
/usr/sbin/
/usr/bin

The original point of sbin versus bin has nothing to do with security and no, the ‘s’ does not stand for super or root user binaries only. It was static binaries. This was important in the days /usr and various other mount points were on separate file systems. Why? Static binary refers to the libraries it needs. Rather than load them dynamically, it was all built into the binary. This was vital when you had a problem on boot up and you needed certain utilities (if e.g., it needed something on /usr – what if that wasn’t mounted for some reason [whatever the case] ? You’d be in trouble). However, over time this changed. Nowadays, in systems prior to UsrMerge (e.g., CentOS), most of the files in /sbin are dynamically linked. In fact, in systemd setups (as opposed to the older init scripts), the /usr isn’t even supposed to be on a separate file system (when I first read that it annoyed me, but I’m ok with it now).

So basically, what UsrMerge does is the following :

Move all files in /sbin, /bin, /lib, /lib64 to to /usr which essentially means move the files, not the directories. After that, whatever was in /sbin is in /usr/sbin, and the same applies to /bin, /lib and /lib64. But what next? It symlinks (e.g., ln -s) the old locations to the new. So, essentially, when you do an ls -l / you will see something like:

lrwxrwxrwx 1 root root 7 Apr 20 13:13 bin -> usr/bin
lrwxrwxrwx 1 root root 7 Apr 20 13:13 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Apr 20 13:13 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 8 Apr 20 13:13 sbin -> usr/sbin

This only has benefits.

The other change I was looking forward to – the default gcc and gcc-c++ packages are now at version 4.7.0. Note I had only one minor problem when updating the operating system. A mis-sight on my part with my libstdc++47 package I built. The problem was file clashing. The solution is simply to remove that package. What I should have done is had /usr/include/c++/4.7.0 in a different directory name. As it is, I only need it on a CentOS 5 machine, which equates to never having libstdc++ 4.7.0, so I”m not concerned about fixing it (especially with such a simple fix – vital especially if you were to upgrade versus fresh install by DVD. The file clashes would stop the installer and then your system could be hosed. So do keep that in mind, folks). Normally I reinstall fresh, but I didn’t want that for a variety of reasons. In the end it was well worth it.

There’s a few addendums I’ll add though. Firstly, the instructions of what I followed are at https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17.

Note though that I had already downloaded the beta DVD as I intended to go that way initially (I downloaded it hours before the official beta was announced; little known fact that its usually obtainable by such time in at least some mirrors). And being on my rather lower downstream link, I did not want to download 1.6GB (which is what yum said I’d have to download). Now, how could I fix that? Well, because I had the DVD, I loop mounted it (see man page for mount, otherwise its : mount -o loop /path/to/image /mountpoint). Then, I initially was going to create a repo but (likely due to me being very impatient and not setting it up right) yum did not want to download via the loop. So, better idea came to mind:

What if I cp the files from the loop-mounted iso image to the location yum downloads the files it needs to? In this case it is /var/cache/yum/x86_64/17/fedora/packages/ (I actually didn’t do cp but rather an rsync as I had downloaded a few there already). As you can probably guess, it means any file that is the same version/release (and all that good stuff) will not have to be redownloaded. That means in my case instead of downloading 1.6GB I had to only download < 900GB. Quite a nice improvement. The only other note that comes to mind: on shutdown, after the update, the kernel could possibly panic (it did in my case after trying [and maybe did succeed - can't recall] - umount the file systems. Since I had no file system issues on power off and then power on (and boot), I assume it did succeed to umount things properly. This may seem like an isue but it's not really that shocking: all the libraries have been updated, kernel, the environment, everything. Next shutdown should go fine.

Aside from that, make sure you heed the warning about dracut and the kernel: it will assume by default you mean the currently RUNNING kernel. That means if you installed any kernel and have not booted into it, then you either must remove that kernel (by version and architecture!! That is essential.) or reboot into the new kernel before building your initramfs. I should point out another thing about initramfs: that's another reason why /sbin didn't care about libraries being statically linked or not - it has the modules/etc that you need to boot up with that kernel. Regardless though, UsrMerge works fine, and no bugs that I can see in Fedora Core 17. Of course, there is one issue for debugging with selinux enabled. However, you simply have to disable that flag (it's related to SELinux denies access to the ptrace system call). Simply doing 'setsebool deny_ptrace 0' will solve that (and if you use debuggers or programs such as strace, then you'll need that). Otherwise, see for more information.