Open devanl opened 8 years ago
check and see if the output of the script has any errors related to copying over the new kernel. it normally will roll back the changes if one piece fails. my guess is that the install script didn't properly catch the exit code of the install, and thought everything was ok.
I don't see anything obvious, there are a lot of lines about removing the diversion but I'm not sure what that means.
Here's a pastebin of the install: http://pastebin.com/gQi1r3Zy
interesting. it's hard to debug without access to the machine, but my new guess is that kernel building failed, but the rest of the packaging didn't.
try running adabuild
again, and check for any errors in the output. it should be faster the 2nd time.
I believe this has something to do with a recent change to the Raspberry Pi Tools repo, which states in https://github.com/raspberrypi/tools/tree/master/mkimage: "The mkknlimg and knlinfo utilities are now found in the scripts directory of the Linux tree". Kernel-o-Matic's build.sh file still points to "${TOOLS_DIR}/mkimage/mkknlimg".
Sorry if it seems like I'm feeding this piecemeal but here's the build for that install... http://pastebin.com/UL61EvD1 Could this be what you are referring to?
/usr/sbin/adabuild: line 171: /opt/rpi_tools/mkimage/mkknlimg: No such file or directory
I don't see the tool there, but it does have other locations...
vagrant@vagrant-ubuntu-trusty-32:~$ ls /opt/rpi_tools/mkimage/ args-uncompressed.txt boot-uncompressed.txt first32k.bin imagetool-uncompressed.py README vagrant@vagrant-ubuntu-trusty-32:~$ find / -name mkknlimg 2>/dev/null /kernel_repos/raspberrypi/linux/v1/scripts/mkknlimg /kernel_repos/raspberrypi/linux/v2/scripts/mkknlimg /kernel_repos/adafruit/adafruit-raspberrypi-linux/v1/scripts/mkknlimg /kernel_repos/adafruit/adafruit-raspberrypi-linux/v2/scripts/mkknlimg
Same tool?
I noticed this too:
vagrant@vagrant-ubuntu-trusty-32:~$ cat /opt/rpi_tools/mkimage/README The mkknlimg and knlinfo utilities are now found in the scripts directory of the Linux tree, where they are covered by the kernel licence.
Note also that the firmware shipped with 4.4 kernels now assumes the kernel is Device Tree-capable unless there is a trailer to say otherwise, meaning that these tools aren't needed for most situations.
@ncguk thanks for the tip!
@devanl want to check out the mkknlimg
branch that is part of #20 and give it a shot?
This certainly changed the build process. The RPi is failing to boot now. It turns on with the rainbow splashscreen and just sits there. Any tips on reverting? Thx
Hmm. I've just built a kernel using the mkknlimg branch and attempted to install it on a Pi Zero. sudo./install.sh starts off okay, then gives this error:
Unpacking raspberrypi-bootloader (1.20160616-1) over (1.20160523-1) ... dpkg: error processing archive raspberrypi-bootloader_1.20160616-1_armhf.deb (--install): trying to overwrite '/boot/bcm2708-rpi-cm.dtb', which is also in package raspberrypi-kernel 1.20160523-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
and then:
Errors were encountered while processing: raspberrypi-bootloader_1.20160616-1_armhf.deb Error completing: dpkg
The only errors from sudo adabuild are:
dpkg-architecture: warning: specified GNU system type arm-linux-gnueabihf does not match gcc system type i686-linux-gnu, try setting a correct CC environment variable
and
dpkg-gencontrol: warning: Depends field of package libraspberrypi0: unknown substitution variable ${shlibs:Depends}
These are same errors I saw before using the new mkknlimg branch, which resulted in a failed install.
hmm. they must have changed the debian package steps recently. i'll take a look
I've tried this a few times now, sudo adabuild -r raspberrypi/linux -b rpi-4.4.y
will create an installer that fails to boot the RPi B+ (stuck at rainbow boot splash). The branch does not appear to matter but, I wanted to be concise.
Coming back to this, I've found that if, in install.sh
I change
exitonerr dpkg -i raspberrypi-bootloader*
exitonerr dpkg -i libraspberrypi0*
exitonerr dpkg -i libraspberrypi-*
to
exitonerr dpkg -i --force-all raspberrypi-bootloader*
exitonerr dpkg -i --force-all libraspberrypi0*
exitonerr dpkg -i --force-all libraspberrypi-*
then this brute forces its way past the
Unpacking raspberrypi-bootloader (1.20160813-1) over (1.20160523-1) ...
dpkg: error processing archive raspberrypi-bootloader_1.20160813-1_armhf.deb (--install):
trying to overwrite '/boot/bcm2708-rpi-cm.dtb', which is also in package raspberrypi-kernel 1.20160523-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
error, the kernel install completes and in my test case (number of successes: 1 of 1), the Pi will boot with the custom kernel.
Obviously this is all kinds of ugly, but it narrows down the problem and perhaps with that a more elegant fix will come.
I'm using the following command line to build a custom kernel:
sudo adabuild -r raspberrypi/linux -b rpi-4.1.y
This ends with:
I copy this over to me RaspberryPi B+ and install with
sudo ./install.sh
ending in:When I reconnect, the kernel does not appear to have been applied (note that the 4.1.y branch was used and the build date does not match).
It appears that the kernel is either not being installed or, not being booted. Is there a boot configuration I should be check?
Thanks, Devan