Stretch Support

[jetbalsa]

Here is what I did to get Stretch working with ua-netinst, Ran will full CDE Debug to make sure everything went well, the curl shim was needed because cdebootstrap requires curl and including it was too much work when busybox wget was fine. Tested on a rPi B+ v1 (512MB) with the 1.1.x branch

• Still Built the base image as Jessie
• Updated cdebootstrap to cdebootstrap-static_0.7.6_armhf.deb by removing the one that update.sh downloaded and placing the updated deb in place, no renaming needed
• edited build.sh to include a curl shim into /bin/curl

#!/bin/busybox sh
while [[ $# -gt 1 ]]
do
key="$1"

case $key in
    --output)
    OUTPUT="$2"
    shift # past argument
    ;;
    *)
            # unknown option
    ;;
esac
shift # past argument or value
done
/bin/busybox wget --output "${OUTPUT}" $1

• edited build.sh to always include systemd

[jetbalsa]

I have plans to test for some failure modes in the curl shim for cdebootstrap but using just a normal install it worked well.

[diederikdehaas]

full CDE Debug

= cdebootstap --debug ?

curl shim was needed because cdebootstrap requires curl and including it was too much work when busybox wget was fine.

You could consider using busybox from stretch too, which no longer prefers applets:

busybox (1:1.22.0-19) unstable; urgency=medium

  * busybox-udeb, udhcpc: Remove /udhcpc/usr/share/udhcpc/default.script,
    erroneously included in version 1:1.22.0-18
  * Disable CONFIG_FEATURE_PREFER_APPLETS in standard build (Closes: #821307)

 -- Ben Hutchings <ben@decadent.org.uk>  Sun, 17 Apr 2016 16:37:24 +0100

source but you could run into other issues though ... (haven't tried it myself yet)

[jetbalsa]

Yep, I ran it with --debug to see the output from wget, found a issue where it installs a really old kernel, doing some package overrides now.

[diederikdehaas]

Which kernel version? Are you trying to install a kernel headers or dkms package? See https://bugs.launchpad.net/raspbian/+bug/1532559 for that then

[jetbalsa]

it had installed something like 3.19. I'm forcing 4.4 with a packages= config line to see what it does right now

[diederikdehaas]

Ah yeah, crap. I did report it to plugwash quite some time ago, but apparently he didn't fix it :-/

[jetbalsa]

Blah, Also holy hell is there a ton of hard coded paths in build, would be nice to be a little more flexible with it as Debian changes ( I had gone down a path to try and include curl and all its libs and promptly gave up on that)

[diederikdehaas]

Do an aptitude search linux-image on a stretch system and you'll likely won't find the 4.4 kernel. If that is indeed the case, you need to add jessie sources.

holy hell is there a ton of hard coded paths in build

could you report (in detail) each an every issue you encounter? Would help us in getting stretch support ootb working.

[jetbalsa]

Sure thing, want them as separate issues?

[diederikdehaas]

nah, dump them all here ;-)

[jetbalsa]

So, besides cdebootstrap being buggy in the older versions, the curl shim was the bigger issue, Im doing another test install now with the force 4.4 package (It is in the release, I had to grep the packages list 👍 )

[jetbalsa]

We really should look into porting debian installer outright to rPi, Wonder how that would go

[diederikdehaas]

That would be a MAJOR task and it would be hard to support the features the installer now has. The first attempt at doing that just died at some point. Dunno whether that's because it was too hard or the author lost interest though. See https://raspbian.org/RaspbianInstaller

[jetbalsa]

I figured as much, looking at even how complex debootstrap is, its no surprise. I did notice that the rPi Foundation repo does not support stretch yet.

[jetbalsa]

Oh well thats interesting, it didn't install init at all -- looks like it skipped over systemd

[jetbalsa]

kernel=vmlinuz-3.18.0-trunk-rpi found in the config.txt - forcing it to the 4.4 kernel it installed

[jetbalsa]

wont boot with 4.4, sitting at rainbow. Interesting.

[diederikdehaas]

That's strange. There are 1 or 2 newer RPi revisions that are not supported by the firmware, but yours shouldn't be a problem. Have you checked your /boot/config.txt file if it may be pointing to the wrong kernel?

[jetbalsa]

So it booted with 3.14 kernel, just no init, with the extra 4.4 install it just sat there at rainbow

I noticed that this line: KERNEL_VERSION=$(sed -n -e "/^Package: ${kernel_meta_package}$/,/Package: /{s/^Depends: .*linux-image-\(.*-rpi2\{0,1\}\).*$/\1/p}" /rootfs/var/lib/dpkg/status) in rcS might be at fault for selecting the wrong kernel

[diederikdehaas]

You should see that then in the installer log file. Normally it installs a kernel meta package for your Pi version, which in turn installs the real kernel. But no init sounds really strange ...

[jetbalsa]

Package: linux-image-rpi Source: linux-latest (63+rpi4) Version: 3.16+63+rpi4 Architecture: armhf

Found in the Packages list forStretch

[jetbalsa]

Im looking at all the packages around linux-* and most are pointing to version 3.10~ of the kernel

[diederikdehaas]

That is REALLY strange. I first thought you made a typo and actually meant 3.18. For the RPi 1, it should install linux-image-rpi-rpfv (source)

[jetbalsa]

it was 3.18, but 3.18 was before systemd support I think, thats why init broke I'm going to make a mod to rcS to prevent linux-image-rpi-rpfv being installed. I think its confusing dpkg

[jetbalsa]

just did a quick edit to change kernel_meta_package to linux-image-4.4.0-1-rpi and linux-image-4.4.0-1-rpi2

[diederikdehaas]

3.18 was before systemd support I think, thats why init broke

nope, it has to be sth else.

I'm going to make a mod to rcS to prevent linux-image-rpi-rpfv being installed. I think its confusing dpkg

That sounds unlikely to me.

What you should check is whether the init package is installed. That in turn installs systemd by default. What would help is if you can share log files (make sure passwords are blanked out) so I/we don't have to speculate, but can investigate.

[jetbalsa]

Ya, Im just using defaults on the installer for testing, Im on a windows host so ext4 is kinda hard, If this install fails, Ill get you those logs

[jetbalsa]

found the issue: Adding boot config for kernel version: '' Copying kernel to /boot/kernel.img... cp: can't stat '/rootfs/boot/vmlinuz-': No such file or directory FAILED ! Creating default cmdline.txt... OK

The full log is here

Its a uncaught error in the rcS at the end of the install, I'm making a full disk image for inspection now

Kernel.Img is completely missing! renaming the vmlinuz- for this now

[diederikdehaas]

That means that it didn't have/find the kernel meta package, which in turn make other things fail. And that cp statement should check whether the source actually exists :-P

[jetbalsa]

so it all stems back to the meta packages being broke :3

[jetbalsa]

so trying with the installer's kernel.img in the config fails to boot with the 4.4's intramfs image, just sits at rainbow

kernel=kernel-rpi1_install.img initramfs initrd.img-4.4.0-1-rpi

[diederikdehaas]

so it all stems back to the meta packages being broke :3

You can say that again, omg:

diederik@rpi2-stretch:~$ aptitude show linux-image-rpi2-rpfv
Package: linux-image-rpi2-rpfv
Version: 4.4+63+rpi5
State: installed
Automatically installed: no
Priority: optional
Section: kernel
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: armhf
Uncompressed Size: 29,7 k
Depends: linux-image-4.4.0-1-rpi2
Description: This metapackage will pull in the raspbian kernel for the raspberry pi 2
 based on the version currently reccomended by the raspberry pi foundation (currently 3.18).

diederik@rpi2-stretch:~$ aptitude show linux-image-rpi-rpfv
Package: linux-image-rpi-rpfv
Version: 3.18+63+rpi4
State: installed
Automatically installed: no
Priority: optional
Section: kernel
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: armhf
Uncompressed Size: 29,7 k
Depends: linux-image-3.18.0-trunk-rpi
Description: This metapackage will pull in the raspbian kernel for the raspberry pi 1
 based on the version currently reccomended by the raspberry pi foundation (currently 3.18).

[diederikdehaas]

And IIRC 3.18 does indeed not work with the (latest) firmware version

[jetbalsa]

Yep, Kernel is refusing to load the intrd image guess its just not finding it

[diederikdehaas]

can you post/share your /boot/config.txt? And the result of ls -l /boot/?

[jetbalsa]

Sorry, I had posted a snippet of it earlier

[pi1]
kernel=kernel-rpi1_install.img
initramfs initrd.img-4.4.0-1-rpi
boot_delay=1
[pi0]
kernel=kernel-rpi1_install.img
initramfs initrd.img-4.4.0-1-rpi
boot_delay=1

[jetbalsa]

Here is the Content of the entire /boot

[jetbalsa]

I should note that I have gotta a dist-upgrade from a normal jessie install to work on a pi1

[diederikdehaas]

That kernel and initramfs line does not seem correct. Here's what I have:

$ cat /boot/config.txt 
[pi1]
kernel=vmlinuz-3.18.0-trunk-rpi
initramfs initrd.img-3.18.0-trunk-rpi followkernel
# to enable DeviceTree, comment out the next line 
#device_tree=
gpu_mem=32M
[pi2]
kernel=vmlinuz-4.4.0-1-rpi2
initramfs initrd.img-4.4.0-1-rpi2 followkernel
#kernel=vmlinuz-4.6.0-1-armmp-lpae
#initramfs initrd.img-4.6.0-1-armmp-lpae followkernel
gpu_mem=32M

So yours should be like:

[pi1]
kernel=vmlinuz-4.4.0-1-rpi
initramfs initrd.img-4.4.0-1-rpi followkernel
boot_delay=1
[pi0]
kernel=vmlinuz-4.4.0-1-rpi
initramfs initrd.img-4.4.0-1-rpi followkernel
boot_delay=1

[diederikdehaas]

Reported the (wrong) 3.18 kernel dependency here: https://bugs.launchpad.net/raspbian/+bug/1663944

[jetbalsa]

Still no boot on the rPi1 or a piZero, Tested Hardware with working image onto same SD card (Jessie Install) initramfs might be bad

[diederikdehaas]

And without the boot_delay line?

[jetbalsa]

Still no go, there are no boot codes (green LED not blinking) as well, Just rainbow

[jetbalsa]

thanks for all the fast responses on this, if you are at defcon this year, I owe you a few beers

[diederikdehaas]

Then I'm out of ideas (for now). So the easiest way for now is installing a minimal system with jessie and then do the dist-upgrade.

Adding support for stretch is on my radar, but first need to fix some other things :-P

[jetbalsa]

Yep, it boots with a jessie initramfs (from my other default install from master branch) and init is STILL missing

[jetbalsa]

Ill be mulling over the build scripts once they fix the meta packages, Ill start doing a audit on the Stretch packages and make sure nothing else stands out as broken (Ill Compare Mainline debian's packages to raspian)

[jetbalsa]

Im going to do some testing in a chroot and see what cdebootstrap is messing up, it looks like a package is missing or config scripts are missing something (package included scripts)

[jetbalsa]

So I've been doing some research and found a few tools floating around, Hexxeh/rpi-update is really nice for installing the latest firmware / kernel outside of the current repo, no matter the dist uses a mirror off the rpi.org repo for firmware as well. im going to whip up a mod to rcS to use it for the kernel install, you would need to do it chrooted into the rootfs when you use it since all the depends it has.

[diederikdehaas]

I (strongly) recommend you don't do that. The rpi-update tool is meant for kernel development, not for regular use. It can literally break from one commit to the next.

What you can do, is use the kernel+firmware from the raspberrypi.org repository. The kernel+ firmware you can get via rpi-update, after stabilization and testing, is made into the kernel package from the raspberrypi.org repository. If you go that route, you'll likely need to remove the 01vcgencmd.pref file from apt preferences as that is specifically used to force the raspbian.org one, but the one from raspbian.org and raspberrypi.org are mutually exclusives (breaks relationship in Debian terms).