Fedora 11, kernel-PAE, and what it means for your x86-32 system

There is one small change in Fedora 11 that I guess will confuse Fedora and RPM Fusion users with x86-32 (aka i386/ix86) systems quite a lot, but afaics did not get enough attention yet:

• By default, the PAE kernel will be used on 32-bit hardware, where appropriate(¹).

"Appropriate" is not really explained -- maybe because it's a bit hard to sum up without going into the boring details. But basically it boils down to: The kernel with PAE support will be installed by Fedora 11 for x86-32 on the majority of x86-compatible systems that have been manufactured in the past three or four years(¹). So likely on your system as well if you are running a x86-32 distro on a modern system.

The important part: the package containing the kernel with PAE support is not called "kernel" -- it's called "kernel-PAE" instead. And that's not the only package where "-PAE" is used as suffix. That has major certain consequences on systems where Fedora 11 installs kernel-PAE:

• when you build kernel modules with akmods, dkms, or manually, then you from now on need to install kernel-PAE-devel instead of kernel-devel
• similar for kernel-modules: instead of "yum install kmod-nvidia" your now need to type "yum install kmod-nvidia-PAE". Yum otherwise will try to install the matching kernel without PAE support for you, which (in short without the boring details) is something you most of the time don't want(²).

In other words: the change in Fedora 11 makes lots of howtos, FAQs, articles on the net and in computer magazines confusing, wrong, misleading or harmful (depending on view and specific howto/FAQ/article), because most of those docs don't consider the above fact (yet).

And that's not Fedora's fault -- PAE kernels are around for a long time in Fedora already. But they were used only on a minority of systems. Most (not all!) of those that have written today's howtos, FAQs or articles were likely either not aware of it or chose to ignored it to keep things simple.

That's backfiring now. So go and spread the news on mailing lists, forums and other places where it might be of interest. Feel free to copy-n-paste this whole text or simply point to this blog entry. Thanks in advance!

(¹) E.g. since processors with NX bit became mainstream; NX stands for NoeXecute and is also called Enhanced Virus Protection by AMD and xD-Bit by Intel

(²) not sure, but maybe the yum-plugin "yum-fedorakmod" could have made yum to the right thing and install the proper kmod for the PAE kernel. I never tried and it doesn't matter much as the plugin is not available in the Fedora or RPM Fusion repositories for F11. If someone wants take care of yum-fedorakmod and wants to get it into RPM Fusion then please drop me a line.

What questions would you like to ask the Fedora Board or FESCo Candidates?

Several seats of the Fedora Board and FESCo are up for election soon(¹). Right now we are in the nomination period, which will be followed by a "Candidate Questionnaire." That means we give candidates a list of questions to answer by mail before the Town Hall meetings on IRC happen.

Candidates may choose to answer (or not) those questions as they see fit. Voters can use the answers to get an impression of what the candidate think or plan to do while serving for the Board or FESCo. That should help to get a interesting discussion running during the IRC Town Hall meetings. Furthermore, those people that can't or don't want to participate in the IRC meetings can use the answers to make a more informed vote.

Hence we need to prepare a few good questions that we can send to the candidates once the nomination period ends. And that's where I need *your help*: If you have one or more questions you'd like to send to the candidates simply go and add them to:

https://fedoraproject.org/wiki/Elections/Questionnaire

It just takes a minute or two, so best to do it right now -- otherwise you might get distracted and forget about it. ;-)

I'll take care of the remaining work to review, sort, and clean up the questions(²), and send them to the candidates after the nomination period ends. Hence, I need them by around the 27th of May. I'll later collect the answers from the candidates and put them up for pubic consumption to give people enough time to read them before the town hall meetings start.

So go to the wiki and add at least one hard question! The answer will help Fedora contributors to chose whom to vote for!

Thanks for your help in advance.

(¹) If you haven't read about it yet see https://fedoraproject.org/wiki/Elections for details.

(²) If you want to get involved or review the questions before I send them please drop me a line and I'll try to get that arranged

Unprofessional

Dear GNOME project,

thanks for running the "GNOME 3.0 General Sociological Research" survey and putting the results online.

A small note: If you ask people if they use foo, bar, baz or foobar and most people select foo, that that's it. Nothing more. And definitely don't conclude "Nearly ³/₄ of the people use foo for it's stability, compatibility and ease of use", because the latter part is a personal option if there wasn't a question "why do you use foo" with checkboxes "stability", "compatibility" and "ease of use" next to it.

Personal opinions like that render the whole conclusion unbelievable and make things look highly unprofessional.

rpmusrtools?

The rpmdevtools are in Fedora for quite a while now and really helpful in a lot of situations. So are the tools in the yum-utils. But the tools in those two packages don't completely satisfy all my needs, hence I (ages ago) wrote a few small scripts that do some additional magic:

• run "rpm -V" on all the packages and look out for packages where files are (a) missing or (b) corrupted; the script as a bonus (c) can even print out config files that have been modified (which likely should be part of a separate script, as that might be handy for backup purposes); if likely (d) should offer to reinstall packages that have missing or corrupted files
  
• run something like "find /bin/ /boot/ /etc/ /lib/ /opt/ /sbin/ /usr/ /var/" with "-type f" and/or "-type d" and let rpm check if the list of files and/or directories that find outputs are owned by a package -- complain if not; that's quite a lot of work for the system and takes a while to complete, but often turns up a whole lot of old and obsolete cruft that is lying in some hidden corner of the hard disk just waiting to get erased (just checked a random machine; 3241 files sum up to 380 MByte...)
  
• run something like "find /boot/ /etc/ /opt/ /usr/ /var/" with "-name '*.rpmnew'" "-name '*.rpmsave'"; go through the list of files find outputs, show a "diff -u" and offer the user to either
  
  
  • run tools like meld or kdiff3 to merge the files(¹) and remove the .rpm{new,save}-file afterwards
    
  • replace the file with its .rpm{new,save}-pendant (or do it semi-automatically if sha1sums are identical)
    
  • delete the .rpm{new,save}-file
    
  • do nothing
  
  
• a script that calls all the above tests as well as "package-cleanup" sequentially with the options "--problems", "--orphans", and "--dupes" to generate a report of "unusual" things
  

All my scripts are quite rough and not really ready for general consumption. But I wonder if it would be worth to collect scripts like these (a lot of users likely have similar scripts), pick the best ones, clean them up in a fedorahosted project and ship them in a package "rpmusrtools" within the fedora repositories.

Dear reader: Would you find such a package useful? Or are there already such scripts/tools somewhere in the big Fedora package collection and I'm just not aware of them?

(¹) that works quite well for a lot of config files, but breaks horrible for those that have lots of comments in them that try to explain each and every option and/or variable :-(( it get even worse if those comments change every few months.

So this goes to the authors of dovecot, postfix, squid, and other software that has lots of comments in their default config files: "Config files are for configuration and should not contain lots of comments that get adjusted every few months, as those make it really hard to merge older (modified) config files with new one; in the future please consider to explain all option in a proper document like a man-page instead please and remove the comments from the config files! Thanks in advance! Yours truly, Thorsten Leemhuis"

I really wish we could get rid of ".fcXY" as disttag in rawhide

I really wish we would get rid of using ".fcXY" as disttag in rawhide because it confuses way to many people when they find packages with tags like "fc7" on their fresh rawhide install... Simply using ".1" as disttag imho would be the best solution.

$ rpmdev-vercmp 1.2-3.1 1.2-3-fc10
0:1.2-3.1 is newer

Then packages that (for good reasons) don't get rebuild during one or two devel cycles don't have disttags from older fedora releases in their package names. But people didn't like it back when I proposed it some years ago. :-/ Hopefully someone sooner or later comes up with a better idea. ".fcn" for "Fedora Collections newest" maybe?

$ rpmdev-vercmp 1.2-3.fcn 1.2-3-fc10
0:1.2-3.fcn is newer

rpm.livna.org is not dead

rpm.livna.org is unreachable -- but that are just temporary DNS problems, so the rumors of livna's death are greatly exaggerated. rpm.livna.org will stay as a add-on to the repositories from RPM Fusion for the foreseeable future.

The rpm.livna.org mirrors still work and yum will automatically use one of them. You can find the release-rpm on mirrors like the one on http://ftp-stud.fht-esslingen.de/pub/Mirrors/ in case you need it for a fresh Fedora install.

Update: The DNS for livna.org will likely be unavailable for at least a few days, likely a week or more. So spread the news to make sure everyone is aware of the fact that rpm.linva.org is still alive and remains usable thanks to the mirrors.

Update2: Use this command to enable livna on a fresh install:

su -c 'rpm -Uvh http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/livna-release.rpm'

After that adjust the repo file to let it retrieve the mirrorlist from one of the mirrors:

su -c "sed -i 's|http://rpm.livna.org/mirrorlist|http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/mirrorlist|' /etc/yum.repos.d/livna.repo"

The latter command should be used as workaround on exiting Fedora install as well if yum is unable to retrieve the mirrorlist!

Some notes on RHEL 5.3

Congrats to the RHEL team for getting RHEL 5.3 out. Some random thoughts that sprung to my mind when looking closer at it:

• The release announcement (short), the Red Hat Enterprise Linux 5.3 Technical Overview (medium sized) and the release notes (all the details) are really great resources to see what's new in the latest RHEL release. I wish we had similar documents for each new Fedora release (yes, we have the release notes, but they contain a lot of boring details regular Fedora users already know).
  
• The kernel and dmraid in RHEL 5.3 now support dmraid 4/5/10. Alasdair, Heinz, others in RH: can you *please* speed up now to get that code (which is developed for quite some time now) upstream for Linux 2.6.30 to make sure it gets into Fedora 11 and from there into RHEL 6? I guess many users would be glad about that, as a lot of newer amd, intel and nvidia chipsets for desktop mainboards support RAID 5.
  
• Many thanks in advance to the CentOS folks that already started to work on CentOS 5.3
  
• I guess it will be an interesting comparison if somebody would compare the number of improvements (and their impact) that RHEL did between 5.2 and 5.3 with those that Ubuntu LTS 8.04.2 brings ;-) [Update 20090123]: Bad timing, 8.04.2 came out just a few hours after I wrote this; list of changes is available [/Update]