Historical kernels and kernel-headers?

[larrybaker]

I use DECnet for Linux: the net/decnet device driver in the mainline Linux kernel with the dnprogs from the decnet-linux project at http://sourceforge.net/projects/linux-decnet. I have used it for many years on a CentOS x86_64 system. A year ago I fixed the decnet driver so it would work on Arch Linux ARM on a Marvell SheevaPlug (Kirkwood) ARMV5TE system. At that time, Arch Linux ARM for Kirkwood was the armv5te distribution, running the 3.1.10-33-ARCH kernel.

When I tried the most recent Arch Linux ARM for Kirkwood, DECnet failed. The system hangs. There was a warning message in dmesg from the network routing layer, which I bet is related to the failure. That kernel is substantially more recent: 3.15.8-1. (I had upgraded it from the 3.14.4-1 kernel in the distribution rootfs before building the decnet driver module.)

I built a system today using the armv5te distribution, updated the kernel from 3.1.10-33-ARCH to 3.1.10-34-ARCH, and built the decnet driver module. DECnet for Linux still works on 3.1.10-34-ARCH.

I want to run the Kirkwood Arch Linux ARM distribution, but I have to fix decnet first. There are lots of changes in the decnet code and in the kernel networking code between 3.1.10 and 3.15.8. I want to try successive kernels between 3.1.10 and 3.15.8 to figure out when decnet breaks. When I asked pacman for a more recent linux on the armv5te system, 3.15.8-1 is it; pacman doesn't seem to know about anything in between.

Is there an archive somewhere with the linux kernel, modules, and kernel headers I can grab (like the Arch Rollback Machine for i686 and x86_64 at http://seblu.net/)? It can be either the armv5te or the kirkwood versions.

Thank you,

Larry Baker
US Geological Survey

[moonman]

There is a. Rollback machine, but it only started working fairly recently http://rollback.archlinuxarm.org/packag ... -kirkwood/. Beyond that you will have to compile your own. You can use git to get older pkgbuilds.

[larrybaker]

Thank you moonman. That is hopeful.

Where are the instructions for locating the previous Arch Linux ARM kernels? Or, where are the patches that are needed to apply to a mainline kernel? I don't build Arch packages, and I'm not sure it is worth learning how to do that. As long as I can self host the kernel build, I should be able to try successively newer stable kernels and fix whatever is broken in decnet.

Larry Baker
US Geological Survey

[moonman]

Before it was just "linux" up until the 3.1 there was a bug in uboot that wouldn't allow devices boot past this version. "linux-kirkwood" was introduced around 3.5 for devices which received an update to uboot. So there are some versions missing.
https://github.com/archlinuxarm/PKGBUIL ... x-kirkwood

Building packages is super easy: install base-devel and run "makepkg" in the directory with PKGBUILD file. You might need memset.patch for older kernels to get them to build with gcc 4.8

[larrybaker]

moonman,

I have made some progress.

I cloned the Arch Linux ARM git repository, then exported (archive) a tar ball from the time of the oldest (3.4.5) Kirkwood kernel.
$this->bbcode_second_pass_code('', '# cd /opt/archlinuxarm
# git clone git://github.com/archlinuxarm/PKGBUILDs.git
# cd PKGBUILDs
# git archive --format=tar --prefix=3.4.5-kirkwood/ 3382450ae4658fe1b887af0517e71cd5d5391649 | gzip -9 >../3.4.5-kirkwood.tar.gz
# cd ..
')
I edited /etc/makepkg.conf to remove "-Wl," from LDFLAGS so the kernel would build.
$this->bbcode_second_pass_code('', '# sed -e '/^LDFLAGS=/s/-Wl,//' -i /etc/makepkg.conf
')
I built the Arch Linux ARM 3.4.5-kirkwood Linux kernel package. (--skipchecksums is because mach-types has been updated.)
$this->bbcode_second_pass_code('', '# tar -xzf 3.4.5-kirkwood.tar.gz
# cd 3.4.5-kirkwood/core/linux-kirkwood
# makepkg --asroot --skipchecksums 2>&1 | tee makepkg.log
')
Unfortunately, makepkg fails at what looks to be near the end of the "Starting package_linux-kirkwood()..." step:
$this->bbcode_second_pass_code('', ' DEPMOD 3.4.5-0-ARCH
make: Entering directory '/mnt/archlinuxarm/3.4.5-kirkwood/core/linux-kirkwood/src/linux-3.4.5'
INSTALL /mnt/archlinuxarm/3.4.5-kirkwood/core/linux-kirkwood/src/cryptodev-linux-1.4/cryptodev.ko
DEPMOD 3.4.5-0-ARCH
make: Leaving directory '/mnt/archlinuxarm/3.4.5-kirkwood/core/linux-kirkwood/src/linux-3.4.5'
depmod: ERROR: could not open directory /mnt/archlinuxarm/3.4.5-kirkwood/core/linux-kirkwood/pkg/linux-kirkwood/lib/modules/3.4.5-0-ARCH: No such file
depmod: FATAL: could not search modules: No such file or directory
==> ERROR: A failure occurred in package_linux-kirkwood().
Aborting...
')
Any suggestions?

Thank you,

Larry Baker
US Geological Survey

[larrybaker]

I think the error is caused by a bug in the linux-kirkwood PKGBUILD.

depmod complains it cannot find a directory.
$this->bbcode_second_pass_code('', 'depmod: ERROR: could not open directory /mnt/archlinuxarm/3.4.5-kirkwood/core/linux-kirkwood/pkg/linux-kirkwood/lib/modules/3.4.5-0-ARCH: No such file or directory
')
Searching for the module directory, we find it is in /usr/lib, not /usr.
$this->bbcode_second_pass_code('', '# find . -type d -name modules
./pkg/linux-kirkwood/usr/lib/modules
# ls pkg/linux-kirkwood/usr/lib/modules
3.4.5-0-ARCH extramodules-3.4.5--kirkwood
')
Just before the depmod step, PKGBUILD moves the module tree from /lib to /usr/lib, but the depmod command is still using /lib to locate the module directory.
$this->bbcode_second_pass_code('', ' # move module tree /lib -> /usr/lib
mkdir -p "${pkgdir}/usr"
mv "$pkgdir/lib" "$pkgdir/usr"

# Now we call depmod...
depmod -b "$pkgdir" -F System.map "$_kernver"
')
I will hack the depmod command in PKGBUILD.
$this->bbcode_second_pass_code('', ' # Now we call depmod...
depmod -b "$pkgdir/usr" -F System.map "$_kernver"
')
Now I just have to wait.

Larry Baker
US Geological Survey

[moonman]

It is not a bug, that's where modules used to be when pkgbuild was submitted. I would take a look at current pkgbuilds (3.1 os a good example) to fix problems like this.

[larrybaker]

I think it is the bug fixed in patch https://github.com/archlinuxarm/PKGBUIL ... f02229c938. I'll find out when makepkg finishes. I used that patch instead of my hack.

[larrybaker]

Yep, that took care of it. makepkg took almost 6 hours! Now I'll start another build to run overnight and test both of them tomorrow.

Thank you.

Larry Baker
US Geological Survey

[pepedog]

Nice to see you taking an interest in arch, Larry