For a long time, this hasn’t been a problem. Now that dracut creates more feature-heavy initramfs files, people were noticing that they were running out of space in /boot during the installation of the kernel rpm. People were asking “why doesn’t rpm check for sufficient diskspace before it tries to install ?” Well, it does. The problem is that for %ghost files, it has no way of knowing how big they are going to be.

So for Fedora 12, we ended up with an ugly hack. Instead of listing the file as a ghost, we create a 20MB empty file, owned by the kernel, which gets overwritten during %post by dracut with the real initramfs.

The big problem with this, is that it destroys the possibility for deltarpms to work. (It also guarantees that signature verification using rpm’s database will fail)

Something better needs to happen, but at this stage, I’m not entirely sure what that will be.

An annoying kernel packaging bug. is a post from: codemonkey.org.uk

No related posts.

The failure mode looks like this:

$ modprobe acpi-cpufreq
FATAL: Error inserting (/lib/modules/…/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

Not particularly informative. We don’t spit out anything helpful to dmesg either. So what is the cause of this problem?
In many cases, /proc/cpuinfo shows the cpu supports speedstep (the ‘est’ flag). The answer in nearly all of these cases is.. The BIOS. The ACPI tables in the BIOS list which P-states a particular CPU supports. If your CPU was manufactured after your BIOS was written, you’re probably going to be out of luck. Sometimes, there are BIOS updates on the motherboard manufacturers website that will add support for newer processors. Sometimes we aren’t so lucky. In these cases, we’re out of luck, there’s nothing we can do.

There is another possibility for the error message above: kernel bugs. We have introduced bugs in the ACPI interpretor in the past which have broken parsing of the P-states on some platforms. These kinds of bugs tend to get noticed very quickly, and fixed in equally short time, but it’s worth making a point that it’s important to be running on the last kernel version before reporting bugs.

When acpi-cpufreq fails. is a post from: codemonkey.org.uk

No related posts.

The kernel offers several configuration options to satisy this question. If you have less than 1G of ram, you don’t need anything special. After 1G, you need to enable CONFIG_HIGHMEM4G. (In actuality, it’s something like 960MB). As the name suggests, this allows you to run kernels that can see up to 4G of RAM. It does this by mapping in/out ‘highmem’ pages (those after the 1G mark) as they are needed. The ‘normal’ kernel for Fedora is HIGHMEM4G.

This sounds like all you’d ever need. Who has more than 4G of RAM ? Even today, typically only servers. However, that mapping/unmapping comes with some overhead, and if you’re using a lot of highmem, you may be better off with the third choice..

Enter PAE (Page Address Extensions). This option is enabled by the kernel config option CONFIG_HIGHMEM64G. Its name tellingly indicates it can support up to 64G of RAM in theory. I say in theory, because there are still a number of really nasty cases that need to be taken care of (Like: the pagetables need to fit in non-highmem memory, and by filling up lowmem with pagetables, you don’t leave much for other purposes). After a point, it just makes more sense to go to x86-64. PAE also gives us the ability to do hardware NX due to it having a wider PTE (page table entry) format.

But there’s another case where PAE is desirable which seems to catch out some people.
If you have exactly 4G of RAM, you may not be able to address it all, even with a CONFIG_HIGHMEM4G kernel.

PCI devices need some physical address space. How much, depends on what PCI devices are present, and how they are configured. This address space needs to live in the lower 4G of memory. So the BIOS carves out a hole in the memory map and says “PCI lives here”. If you had 4G of RAM, you may find the memory map now looks like..

3G RAM : 1G PCI ‘hole’ : 1G RAM

See the problem? To address that top 1G of RAM, we need to use addresses past 4G. And to use those, we need PAE.

x86-32 PAE gotchas. is a post from: codemonkey.org.uk

No related posts.

What I’m toying with doing is some devel kernels for Fedora 11 that are built outside of the Fedora build system. The Fedora kernel team now has enough build bandwidth for x86-[64] that we can actually get builds for those architectures done faster than koji.

Disk space – I’m thinking of just keeping the last 2-3 builds available.

Mirroring – Instead of having these be part of Fedora proper, I think an external repo on something like fedorapeople.org will suffice.

Which just leaves people bandwidth. For the most part the work is going to be just regularly syncing the devel/ branch with a CVS branch of F-11/ For some of this work, some scripting could be done to alleviate some of the pain. Also the frequency at which we push out these builds will determine the pain point. Perhaps every -git isn’t particularly valuable anyway. One build every handful of -git’s should be sufficient for bisecting.

There does remain one additional barrier. Occasionally we introduce something in rawhide builds which just won’t work on F11. For example, the kernel modesetting patches are tied closely to Xorg packages. Sometimes upstream changes require changes in mkinitrd or udev or some other ‘plumbing’. Some of these are regressions, and hopefully by identifying them sooner we can get them reverted/fixed upstream. Sometimes however, things get deprecated, and we need to change these packages. I’m not sure how to cope with this yet in a devel-for-F11 scenario.

One other thing that might be fun to throw into this would be the generation of -vanilla packages. The only reasons we don’t do these as part of the regular kernel builds is the various bandwidth concerns above. The specfile copes with spitting out RPMs with very little work needed. Josh Boyer has been occasionally doing these builds, though there hasn’t been a huge uptake. It’s unclear if this is due to lack of interest, or just a lack of publicity.

Another question to be answered is whether we go the route of enabling debugging in all builds as we do in rawhide, or do separate -debug builds. I’m leaning towards the latter.

I’m not committing anything to this for sure just yet, but it’s something I’ve been giving quite a bit of thought. There are still a bunch of unanswered questions.

Increasing testing of unreleased kernels. is a post from: codemonkey.org.uk

No related posts.

So we’re looking at 2.6.31 for F12. (With various conferences coming up over the next few months, it seems infeasible that .32 will land in time for F12′s release).

Other planned changes? We’ve talked about dropping the exec shield patch that we’ve been carrying since Fedora Core 1.
It’s a pain to have to keep carrying it, and rebasing it, and occasionally fixing it, just to add a poor emulation of a feature that has been in all CPUs for the last five years. The decision isn’t final yet, but it’s something that’s being considered.

Some of the other patches we’ve been carrying (like modesetting drm) are now starting to find their way upstream too, which is obviously a good thing. The only really big thing we’re still carrying that struggles to get upstream is utrace.

Fedora 11 released, onwards to F12. is a post from: codemonkey.org.uk

Related posts:

1. exploded Fedora devel tree. I did a make prep of every package in the...

The current state of the diffs is at http://www.codemonkey.org.uk/projects/execshield/.

The emulate-NX-with-segment-limits chunk is unlikely to ever go upstream. A bit of a shame given it’s the largest part of execshield remaining. Linus wasn’t thrilled by it, and it is a pretty nasty hack.
Also, with modern CPUs having hardware-NX, it becomes less useful over time. (Though we still need to carry it judging by the number of old-school 686 users we still have).

So if we do have to keep execshield, we should at least try to make it cleaner and smaller. Every time I poke at it, I manage to shave off another hundred lines or so.

execshield split-up. is a post from: codemonkey.org.uk

No related posts.

In F11, at install-time, Anaconda will install the PAE kernel if the CPU is capable of using it, and otherwise, will fall back to the 586 kernel. (Users upgrading with yum will see a 686->586 transition unless they are already using the -PAE flavour)

Both kernels actually have instruction scheduling optimised for 686 (Using gcc’s -mtune=generic, which optimises for the popular CPUs of the time).

The actual differences between the two builds:

586:

• Uses only up to the i586 ISA

• Supports up to 4GB of RAM.
• Will use segment limits to approximate NX.

686-PAE:

• Uses the 686 ISA including CMOV.

• Uses 3-level page-tables allowing >4GB RAM.
• Where possible, uses hardware NX instead of segment limits. (faster)
• Has Xen virtualisation enabled.

Processors that will need to use the 586 kernel include..

• all AMD CPUs prior to the Athlon

• Intel Pentiums prior to the Pentium Pro
• Some subset of Intel Pentium M’s (These are the only ‘modern’ CPUs)
• All Cyrix and Transmeta
• All VIA prior to Esther

Fedora kernel packaging changes is a post from: codemonkey.org.uk

Related posts:

1. An annoying kernel packaging bug. The kernel rpm package creates an initramfs file that gets...
2. exploded Fedora devel tree. I did a make prep of every package in the...

So to begin with, clone the git repo from git://fedorapeople.org/~katzj/dracut.git (This will move soon, as Jeremy asked me to take over the lead on dracut, but until there’s additional changes, go there).

After a brief cloning, you’ll be left with a dracut directory containing a bunch of interesting files..

‘dracut’ is the shell script that will actually generate an initramfs image. It sources the ‘dracut-functions’ script to do some of the trickier things like working out module dependancies. This script will eventually get called by the kernel during its build process as part of ‘make initramfs’.

dracut.spec is an RPM spec file, handy for testing on Fedora systems until we get the kernel bits hooked up.

‘init’ is the actual init script that ends up in the initramfs.
It achieves quite a lot in its 119 lines.

• Sets up device nodes

• starts up udev
• figures out from the command line what kind of root device we’re expecting
• waits for it to show up in /dev, and mounts it
• mounts /proc and /sys
• If anything goes wrong at all during mounting of the root filesystem, it drops you to a shell.
• If plymouth is present, it starts it, so it can show splash screens, or prompt for an encrypted disk password etc.
• Right now it’s also loading the default selinux policy, though there seems to be agreement that the right place for this to happen is in the real rootfs, in /sbin/init.

There’s a makefile that will install things in the right places if you’re on a Fedora system. (libexec, ugh). If you don’t do this, you can still run dracut directly from the checked out tree, by passing it the option -l

rules.d contains two udev rules. One which scans for LVM volumes when it gets a notification that a new block device has been added to the system, and another which handles encrypted block devices should one show up. Both of these rules are not shining examples of how this should be done, and could use improving.

‘switch_root’ is the sole surviving piece of ‘nash’. Its job is fairly simple. Switch to new root directory and start init from that new root. Right now, we’re calling the nash tool from the existing mkinitrd implementation. The code for the replacement of this currently lives at http://pjones.fedorapeople.org/mkstart/usr/lib/mkstart/switchroot.c It is hoped that this will get included as a util-linux utility soon, so that nash can finally be put to rest.

Finally there’s all the usual things you’d expect to see in a project, COPYING, HACKING, README and a healthy looking TODO.

The interesting parts (the shell scripts) are currently only just over 600 lines, making it a fairly easy to understand project. Removing some of the redhat’isms is definitely one of the things that needs to happen before it can be headed upstream. I hope to get around to trying it out on some other distros later this week.

So with the overview out of the way.. Run the generator directly, with a target filename as a parameter. (Remember to specify -l unless you’ve done ‘make install’), and you should get a compressed cpio archive created in the name you chose.

Currently, dracut supports root on raw disks (/dev/sda), lvm (/dev/mapper…), and mounting root by label or uuid.
If you have a more esoteric rootfs setup, such as root-on-nfs, right now it’ll fail horribly.

That’s the quick braindump that should be enough to get people playing with it. There is a very low traffic mailing list initramfs at vger.kernel.org, (send ‘subscribe initramfs’ to majordomo@vger to get subscribed).

Dracut status is a post from: codemonkey.org.uk

Related posts:

1. An annoying kernel packaging bug. The kernel rpm package creates an initramfs file that gets...
2. Spot the shell bug. This is bugging me. I’m missing something obvious here, and...
3. boot/init miniconf at plumbers next week. I’m MC’ing the boot/init miniconf next week at the Linux...

The thing is, they never could.

From a recent posting to the cpufreq list:

I have a laptop (ASUS W7J) with an Intel Core2 T7200 2GHz.
…
When I use the p4-clockmod, I get:

available frequency steps: 250 MHz, 500 MHz, 750 MHz, 1.00 GHz, 1.25 GHz, 1.50 GHz, 1.75 GHz, 2.00 GHz
…

For every one of those ‘frequency’ options, the CPU is actually running at 2GHz. It never changes speed. Not at all.
The p4-clockmod driver abuses the cpufreq interface to expose a clock modulation feature that has been in processors for a long time. (Even the earlier pentiums had a variant of it). The driver modulates the clock applied to the processor so that instead of every clock cycle meaning the processor gets do some work, only a percentage of the clocks make the CPU do real work. The remainder of the time, the processor just sits there.

So the 1.00GHz ‘frequency’ is actually “run at 2GHz, but only do work 50% of the time”.

On the surface, this sounds like a good idea. The other 50%, the CPU is idle, so you’re saving power, right?
Not so much. In fact, you could be burning more power. The reason for this is that when the processor is sitting there doing nothing, it isn’t lower frequency, and more importantly, it very likely isn’t entering C states. So you’re burning the same amount of power, but now you’re only doing work for 50% of the time. As a result of this, your workload takes twice as long to complete.

If it isn’t saving any power, what is the point of this at all ?
A clue is revealed by reading the Intel programmers guide for this feature; it’s closely tied to the processors thermal monitoring feature. The idea of this feature is that when the CPU overheats, it can ‘back off’ a little, to prevent overheating. The temperature of a processor isn’t constant. When running flat out, it will generate more heat. So by modulating the clock, the maximum amount of heat possible to generate decreases.

The changes merged into the 2.6.29rc kernel remove the user-visible interface, and replace it with direct calls from the ACPI code that gets triggered on thermal events. It’s all entirely automatic now.

Forthcoming p4-clockmod changes. is a post from: codemonkey.org.uk

No related posts.

For the record: It takes an eeepc 901 just under nine hours to build a Fedora kernel.

Yes, dumb idea, but I just had to know.

Building a kernel on the eeepc. is a post from: codemonkey.org.uk

Related posts:

1. Not attending kernel summit. Tomorrow, I should have been getting on a plane, and...
2. An annoying kernel packaging bug. The kernel rpm package creates an initramfs file that gets...