This patch adds a "features.aufs2_1" to the aufs-2.1 patch for Linux
2.6.37 to prevent aufs2_1 and aufs2_1_util from being options for
kernels without an aufs 2.1 patch. There were several Hydra build
failures as a result of attempting to build aufs2.1 against older
kernels.
svn path=/nixpkgs/trunk/; revision=26597
* My motivation for this patch is that kernels < 2.6.36 contain an
e1000e that does not support the ethernet card that is part of the
chipset for the second-generation Core-i Intel CPUs, so in order
to have a more useful livecd I needed to get aufs working with a
newer kernel, and 2.6.37 is the latest kernel with an official
aufs release.
* All sources are downloaded with fetchgit. This is because the aufs
upstream doesn't provide release tarballs, they just add a tag to
their git tree for an official release.
* The make target for the aufs2.1 headers uses a Makefile in the
kernel build directory that requires that unifdef be in the
scripts/ subdirectory of the build directory. The way I've dealt
with this here is by adding "make $makeFlags -C scripts unifdef"
to the postBuild in the kernel builder. Since the builder is used
by all kernel versions, this will require rebuilding every kernel
and kernel-dependent package if the patch is accepted, so one
alternative I thought of would be to create a fake kernel build
directory where everything is symlinked to the real build
directory except scripts/, which is first copied and then make
unifdef is run before building aufs2.1. If that more complicated
solution is preferred, or if anyone has ideas for another one, I
can do that and submit a new patch.
* The patch was tested by building a livecd ISO that uses it, then
running the ISO from within virtualbox and installing aufs2.1-util
from within the livecd environment.
* The livecd was built using installation-cd-minimal.nix, with two
changes to the Nixos tree:
1. boot.kernelPackages = pkgs.linuxPackages_2_6_37 was added to
profiles/minimal.nix
2. config.boot.kernelPackages.aufs2 was changed to
config.boot.kernelPackages.aufs2_1 in iso-image.nix
I would have preferred to keep all changes within
profiles/minimal.nix, but I couldn't figure out how to override
iso-image.nix's definition of boot.extraModulePackages. Livecds
that use an older kernel can't be built with this iso-image.nix,
since we don't have aufs2.1 for them (just aufs2). If someone can
point me to how I can override things set in iso-image.nix, I'd
appreciate it.
make -C scripts unifdef compiles the unifdef application in the
scripts/ directory, and when Nix copies over the build tree to
$out/lib/modules/$version/build for kernel modules to reference, it
copies over all of scripts/ except the .o files. I can't speak for
other kernel versions, but at the least for 2.6.37.1 unifdef is not
built by default. If you look at the Makefile in scripts, unifdef is
listed under a comment saying that the following programs are only
built on-demand.
svn path=/nixpkgs/trunk/; revision=26548
In fact only 2.6.34 boots fine, while 2.6.35 needs a fetchsvn new revision,
waiting for an upstream patch.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23039
properly on Amazon EC2.
* Always apply the CIFS timeout patch. It's rather annoying to have
to build a separate kernel for the VM tests.
svn path=/nixpkgs/trunk/; revision=22630
operations to 120s. This is necessary if the host is heavily
loaded. For instance, in the Hydra build farm, if there are many
concurrent jobs, VM builds often fail because they hit the timeout.
svn path=/nixpkgs/trunk/; revision=22347
The Linux 2.6.34 kernel delivers (from [1])
- many open-source GPU driver updates,
- GPU switching support,
- the LogFS file-system,
- faster KVM networking support,
- Btrfs file-system updates,
- the VMware memory ballooning driver,
- and many other changes.
A more exhaustive list of the Linux 2.6.34 kernel changes from
architectures to network drivers is listed on the Wiki at
KernelNewbies.org.[2]
[1] http://www.phoronix.com:
[2] http://kernelnewbies.org/Linux_2_6_34
svn path=/nixpkgs/trunk/; revision=22023
on the native and cross platforms.
I thought I already did that today in a previous commit, but I did all wrong.
svn path=/nixpkgs/trunk/; revision=20280
I introduce the new nixpkgs parameter "platform", defaulting to "pc",
which was before defined as an attribute of nixpkgs.
I made the crossSystem nixpkgs attribute set parameter contain its own 'platform'.
This allows cross-building a kernel for a given crossSystem.platform in a non-PC
platform.
The actual native platform can be taken from stdenv.platform, and this way we also
avoid the constant passing of 'platform' to packages for platform-dependant builds
(kernel, initrd, ...).
I will update nixos accordingly to these changes, for non-PC platforms to work.
I think we are gaining on flexibility and clearness. I could cross build succesfully
an ultrasparc kernel and a mipsel kernel on PC. But since this change, I should be able
to do this also in non-PC.
Before this change, there was no possibility of distinguishing the "target platform" or
the "native build platform" when cross building, being the single "platform" attribute
always interpreted as target platform.
The platform is a quite relevant attribute set, as it determines the linuxHeaders used
(in the case, by now the only one supported, of linux targets).
The platform attributes are quite linux centric still. Let's hope for more generality to come.
svn path=/nixpkgs/trunk/; revision=20273
It seems that there is no make target named 'vmlinuz' that makes the file 'vmlinuz'.
So we need different variables for the make target and the kernel file. Unless we
some day stop using the file 'vmlinuz' in pc, and use bzImage.
svn path=/nixpkgs/trunk/; revision=20092
"make config" to print an additional question that the script
doesn't know how to answer ("Audio Excel DSP 16 [N/y] (NEW) ###").
Just ignore it.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19713
I fixed conflicts regarding the renaming 'kernel' -> 'linux' in all-packages.
Also a small conflict in all-packages about making openssl overridable.
And I some linux 2.6.31-zen kernel files also marked in conflict.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19438
most of the kernel expressions for the sheevaplug).
I still have not added anything in the kernels about cross compilation.
I moved the platform definitions out of all-packages.
I have not written good platform definitions for the sheevaplug - only for the
PC.
Only the linux-2.6.32 expression uses the platforms kernelConfig.
The linux-2.6.31 was broken, and I left it broken.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19046
sheevaplug kernel, so the kernel does not build in the sheevaplug right now.
I will try to fix that in next commits.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19045
has to be "/bin/sh" - other values such as "sh" or "bash" or "$(type
-tP sh)" cause a build error:
LD .tmp_vmlinux1
/nix/store/1yv8i1m76cvwk5w5i5wrk4gj5zyfj6vh-binutils-2.19.1/bin/ld:arch/um/kernel/vmlinux.lds:1: ignoring invalid character `#' in expression
/nix/store/1yv8i1m76cvwk5w5i5wrk4gj5zyfj6vh-binutils-2.19.1/bin/ld:arch/um/kernel/vmlinux.lds:1: syntax error
collect2: ld returned 1 exit status
This is caused by Bash 4.0
(http://bugzilla.kernel.org/show_bug.cgi?id=13343).
svn path=/nixpkgs/branches/kernel-config/; revision=18941
* Move kernel patches out of all-packages.nix to
os-specific/linux/kernel/patches.nix.
* Make the kernel config available under $out/config (it's also in
$out/lib/modules/$version/build/.config, but that's kind of hard to
find).
svn path=/nixpkgs/branches/kernel-config/; revision=18937
`generate-config.pl' runs `make config' to generate a Linux kernel
configuration file. For each question (i.e. kernel configuration
option), unless an override is provided, it answers "m" if possible,
and otherwise uses the default answer (as determined by the default
config for the architecture). This is safer than allmodconfig,
which answers "y" everywhere it can't answer "m" and thus ends up
enabling a lot of experimental or debug options. (For this reason,
a configuration generated by allmodconfig must be carefully checked
with every new release to ensure that nothing dangerous is enabled.
The default config should be safer wrt new kernel releases.)
Overrides are specified in the `config' argument to generic.nix,
which is a string that contains lines such as `EXT2_FS_POSIX_ACL y'.
The script warns about ignored options, and aborts if `make config'
selects an answer inconsistent with the one in `config'. This
allows us to be sure that `make config' doesn't silently override
our configuration values (e.g., depending on other options, it will
set FB_TILEBLITTING to "y" even if we want it to be "n").
svn path=/nixpkgs/branches/kernel-config/; revision=18910
