fails to build images on debian testing armhf or arm64

[rolandoam]

I'm trying to build a debian testing image for my raspberry pi 3, so far arm64 & armhf fail. Different errors though:

armhf (sudo make distclean && sudo make DIST=testing REPO=Debian DIST_ARCH=armhf IMAGE_MB=1024)

...
Processing triggers for libc-bin (2.24-3) ...
Adding user `pi' to group `sudo' ...
Adding user pi to group sudo
Done.
Adding user `pi' to group `audio' ...
Adding user pi to group audio
Done.
Adding user `pi' to group `video' ...
Adding user pi to group video
Done.
adduser: The group `input' does not exist.
rootfs.mak:64: recipe for target '/home/rolando/Downloads/rpi-img-builder/rootfs' failed
make[1]: *** [/home/rolando/Downloads/rpi-img-builder/rootfs] Error 1
Makefile:21: recipe for target 'build-rootfs' failed

arm64 (sudo make distclean && sudo make DIST=testing REPO=Debian DIST_ARCH=armhf IMAGE_MB=1024)

...
Processing plugins/Debian/u-boot...
 - found files ... adding
 - found packages ... adding
 - found preinst ... running
Cloning into '/tmp/firmware'...
remote: Counting objects: 4324, done.
remote: Compressing objects: 100% (2552/2552), done.
Receiving objects:   2% (116/4324), 12.00Receiving objects:   2% (116/4324), 12.40 Mremote: Total 4324 (delta 1591), reused 2702 (delta 1456), pack-reused 0
Receiving objects: 100% (4324/4324), 80.54 MiB | 534.00 KiB/s, done.
Resolving deltas: 100% (1591/1591), done.
Checking connectivity... done.
 - found postinst ... adding
chroot: failed to run command ‘/bin/bash’: No such file or directory
rootfs.mak:64: recipe for target '/home/rolando/Downloads/rpi-img-builder/rootfs' failed
make[1]: *** [/home/rolando/Downloads/rpi-img-builder/rootfs] Error 127
Makefile:21: recipe for target 'build-rootfs' failed
make: *** [build-rootfs] Error 2

Any ideas what could be wrong or where should I start looking to fix this? Thanks!

[TheSin-]

the package that sets up the group input is missing or something has recently changed, I'll look into it. Thanks for reporting this. Hopefully have it fixed right away.

[TheSin-]

The second error bash is missing in the roots dir, which means the bash package isn't being installed for some reason, I'll check that too, did you make any modifications or is this direct form the report and just issue those commands?

[rolandoam]

thanks for the quick reply! no modifications, the only thing I did was to move the alsa and mountusb plugins as specified in the docs and then running those commands.

[TheSin-]

okay I'm running it now to test then

[rolandoam]

btw, I'm running the script on a Debian testing x86_64 machine

[TheSin-]

perfect same setup as me then, both these errors are int eh chroot so the host shouldn't matter at this point. I committed an fix for the first error, it'll just ignore it and continue on, I'm waiting on the second one, if I can reproduce it I'll make an other commit for it.

[rolandoam]

thanks! will give it a try and let you know

[TheSin-]

BTW arm64 is pretty untested as last I checked it didn't have RPI3 support in the kernel, I'm still testing it now but I'm not sure it'll boot honestly. But the armhf seems fine now, though I'd like to investigate what happened to the input group ;)

[rolandoam]

you're right about arm64, I just wanted to see if it would boot... I'm fine with armhf for now though. (Still building the image)

[TheSin-]

okay so I just checked and dev adds the input user group, so why would dev not install in current testing, I'm going to look deeper into that shortly. Still waiting on the arm64 version to fail currently.

[TheSin-]

okay I think I see what is wrong with arm64 give me a sec I'll have it fixed up.

[TheSin-]

okay so for arm64, u-boot-rpi isn't in testing it's only in unstable, but it should now work once that package is in testing.

As for the input group I've added udev into the common packages, this should fix it, along with making the error non fatal, just running a finally test and I'll close th issue but thank you very much for bring both of these to my attention

[TheSin-]

made a few more tweaks and testing again I think it's good this time honestly ;)

[rolandoam]

thanks a lot for the quick fixes! trying again now.

[TheSin-]

I'm still finishing issues, but I'm getting through them as I can, seems lots of depends changed, it's good I'm finding these now honestly but I'll have to test build raspbian after this to make sure i didn't break that now ;) It's so much fun changing things ;)

[rolandoam]

hmmm... it failed now due to missing /etc/default/rcS:

Running custom postinst scripts
  Running /postinst/hostname-RPXzl
  Running /postinst/fsckboot-eOTrK
/bin/sed: can't read /etc/default/rcS: No such file or directory
rootfs.mak:64: recipe for target '/home/rolando/Downloads/rpi-img-builder/rootfs' failed
make[1]: *** [/home/rolando/Downloads/rpi-img-builder/rootfs] Error 2
Makefile:21: recipe for target 'build-rootfs' failed
make: *** [build-rootfs] Error 2

I'm trying adding the package initscripts to the common plugin to see if that fixes it.

[TheSin-]

already fixed that one I'm waiting to see if there are more, I have to run home but i"ll start a new build as soon as I get home.

[rolandoam]

ok, I was able to build the armhf Debian testing image, but it failed to boot... will try later tonight to see if I can find out what was the problem. (u-boot was not auto-booting, had to type boot to start)

[TheSin-]

okay i'm building a copy and I'll try booting it, I'm not a u-boot expert but I'll join the chan see if I can figure it out.

[rolandoam]

I think the problem could be because (it seems that) the template fstab did not get copied to the target system.

[TheSin-]

you have to mount the ing to see it, it's not in rootfs as it messes up the chroot, it's put in to the ing directly after the copy. I'll check mine to make sure, it got copied but I do not see a reason for it to be missing.

[TheSin-]

it looks like the boot.src on the fat partition might be wrong so I'm just copying the ing back to me so I can dd it

[TheSin-]

oh I see what's there, it's looking for bcm2836-rpi-other.dtb, but the debian u-boot-rpi package only has bcm2836-rpi-2-b.dtb, what hardware you running it on? Debian only supports rpi2b

[TheSin-]

I also see it's looking for vmlinuz now unversioned, I'll see what that is failing to be built.

EDIT: Oh NVM it tries the versioned one first, so it all looks good, I'm going to get and hook up my RPI2 to test it, I setup my RPI3 instead by accident ;)

[TheSin-]

I'm booting but i"m seeing a different kernel panic I'm trying to see where/why, just having some problem with my ttl -> USB adaptor

[rolandoam]

I'm testing in a rpi3...

[rolandoam]

btw, sid seems to support rpi3, giving it a try now: https://packages.debian.org/sid/u-boot-rpi

[TheSin-]

sorry been reinstalling today, I'm still not 100% back up but wanted to comment, I didn't get my tel app working last night which prompted a long overdue reinstall. Let me know how Sid goes I"m still working on RPi2 with testing, as it used to work it's making me nuts ;)

[rolandoam]

I was able to make the image (sudo make distclean && sudo make DIST=sid REPO=Debian DIST_ARCH=armhf IMAGE_MB=1024). I had to make one fix though:

$ git diff plugins/Debian/u-boot/postinst
diff --git a/plugins/Debian/u-boot/postinst b/plugins/Debian/u-boot/postinst
index c84cf28..5904fae 100755
--- a/plugins/Debian/u-boot/postinst
+++ b/plugins/Debian/u-boot/postinst
@@ -6,7 +6,7 @@ echo "flash-kernel flash-kernel/linux_cmdline string earlyprintk console=ttyAMA0

 dpkg-reconfigure -f noninteractive flash-kernel

-cp /usr/lib/u-boot/rpi*/* /boot/firmware/
+#cp /usr/lib/u-boot/rpi*/* /boot/firmware/

 flash-kernel
 /etc/kernel/postinst.d/zzz-fatboot-partition

However, it does not boot :( all I get is the rainbow screen (the 2x2 image stretched by the GPU).

[TheSin-]

does the new u-boot-rpi not install the files in to that dir? I'll see if I can fix this for you give me a few.

[TheSin-]

https://packages.debian.org/sid/arm64/u-boot-rpi/filelist

looks like that line is needed, why did you comment it out? if you do not use the files from u-boot-rpi it just won't work.

[TheSin-]

ahh okay I see now, I missed that you did Sid armhf, I thought it was arm64

So the issue is that it will copy multiple files, you should have changed it like this, try it and let me know

diff --git a/plugins/Debian/u-boot/postinst b/plugins/Debian/u-boot/postinst
index c84cf28..5904fae 100755
--- a/plugins/Debian/u-boot/postinst
+++ b/plugins/Debian/u-boot/postinst
@@ -6,7 +6,7 @@ echo "flash-kernel flash-kernel/linux_cmdline string earlyprintk console=ttyAMA0

 dpkg-reconfigure -f noninteractive flash-kernel

-cp /usr/lib/u-boot/rpi*/* /boot/firmware/
+cp /usr/lib/u-boot/rpi_3_32b/* /boot/firmware/

 flash-kernel
 /etc/kernel/postinst.d/zzz-fatboot-partition

You still need those files, it's important, but you need to right ones, this patch would be rpi3 otherwise change rpi_3_32b for rpi_2 for the rpi2. I'm going to see if I can add an options for this.

[TheSin-]

So I built both stitch and Sid (which the right changes from above) and both start to boot, but there is a problem with the Debian kernel, I'm trying to look deeper into it ATM

reading /vmlinuz-4.7.0-1-armmp
3698952 bytes read in 529 ms (6.7 MiB/s)
reading /dtbs/4.7.0-1-armmp/bcm2836-rpi-2-b.dtb
7294 bytes read in 24 ms (295.9 KiB/s)
reading /initrd.img-4.7.0-1-armmp
14969069 bytes read in 2035 ms (7 MiB/s)
Booting Debian 4.7.0-1-armmp from mmc 0:1...
Kernel image @ 0x1000000 [ 0x000000 - 0x3869e8 ]
## Flattened Device Tree blob at 00000100
   Booting using the fdt blob at 0x000100
   Using Device Tree in place at 00000100, end 00004d7d

Starting kernel ...

[TheSin-]

so I turned off quiet mode so I can see the boot and I might need to blacklist a module

[    4.609733] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    4.619389] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=
1
[    4.629412] usb usb1: Product: DWC OTG Controller
[    4.636833] usb usb1: Manufacturer: Linux 4.7.0-1-armmp dwc2_hsotg
[    4.645708] usb usb1: SerialNumber: 3f980000.usb
[    4.656289] hub 1-0:1.0: USB hub found
[    4.662671] hub 1-0:1.0: 1 port detected
[    5.047908] usb 1-1: new high-speed USB device number 2 using dwc2
[    5.248128] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    5.257455] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    5.273205] hub 1-1:1.0: USB hub found
[    5.280269] hub 1-1:1.0: 5 ports detected
[    5.428158] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. O
pts: (null)
[    5.572870] usb 1-1.1: new high-speed USB device number 3 using dwc2
[    5.670244] random: nonblocking pool is initialized
[    5.678397] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    5.687862] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber
=0
[    5.804802] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00
007f00

[TheSin-]

so I'm at a loss I started to look at the Debian kernel building, and all rpi patches have been removed form the 4.7.x Debian builds. I assumed that meant the 4.7 was RPi combat upstream. Which I was right, but there are bugs, I found this one https://patchwork.kernel.org/patch/9154727/ and I checked the current Debian build and it is not applied, I feel like this patch or maybe others could be our issue here.

BTW it was NOT the usb module and I honestly didn't think it was, it seems to be BCM/IRQ related from further analysis.

[rolandoam]

bummer. I left my pi at work. I'll try again tonight.

[TheSin-]

I'm going to likely use the Debian build but add that patch by hand and see if I can prove that is the issue if I can I'll report it to the Debian kernel team.

[TheSin-]

I have made lots of fixes though so it picks the proper u-boot bin/elf files now, so make sure you update before you build I'm building and testing an RPI3 now, incase that doesn't have the same issues.

[rolandoam]

perfect! I'll let you know how it goes

[TheSin-]

So the arm64 won't build because the kernel doesn't build an rpi dtb, so u-boot-rpi supports it but flash-kernel and linux-image-4.7.0-1-arm64 do not :\

So the only option currently would be armhf, but that one has a kernel issue at boot time, so I'll focus there for now, rpi3 should still work with armhf if you use RPI=3 when you build it.

So I'm going to attempt that variant now.

[TheSin-]

I got it, /sbin/init was missing, an other missing dep. I just booted a Debian build FINALLY

Debian GNU/Linux stretch/sid localhost ttyAMA0

localhost login: pi
Password: 
Linux localhost 4.7.0-1-armmp #1 SMP Debian 4.7.5-1 (2016-09-26) armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
pi@localhost:~$ uname -a
Linux localhost 4.7.0-1-armmp #1 SMP Debian 4.7.5-1 (2016-09-26) armv7l GNU/Linux

Thanks again for reporting these issues, sorry it took me so long, the error was very vague honestly, which is surprising for linux and I'm not sure what changes upstream with Debian depends but man that was a PITA :)

[rolandoam]

thanks! I'm trying now with the new RPI=3 option. Let's see how it goes. (using sudo make distclean && sudo make DIST=sid REPO=Debian RPI=3 DIST_ARCH=armhf IMAGE_MB=1024)

[TheSin-]

let me know as I didn't fully test it yet.

[TheSin-]

IIRC it won't work, u-boot has the right bin code in testing, but not in Sid, also both are missing the rpi3 dtb from the kernel. so basically Debian has no kernel support for the device tree for rpi3 at all. :\

[TheSin-]

oh and I need to make a db entry for rpi3 in flash-kernel once the dtb is avail. so there are pieces from Debian I'm still waiting on for rpi3 support sadly :\

[rolandoam]

that sucks... I guess we'll just have to wait then :)

[TheSin-]

the db part I can do myself the dtb though I'd have to custom build the kernel and lock it so it's not a great option sadly :. 4.8 supports pi3 natively so once Debian finally hits 4.8 we'll be in business. I'll see if I can add a ticket to have a patch added to 4.7 though.

[TheSin-]

looks like today is the day, with 4.8 in testing https://packages.debian.org/stretch/u-boot-rpi was updates and looks like it has support for armel, armhf and arm64 finally!

I'm hoping to carve out a little time today or tomorrow to test armhf and arm64.

[TheSin-]

I'm just testing builds with the last few things I need for Debian testing arm64 build, sadly I didn't bring my RPi3 home this weekend to fully test but I'll likely commit my changes anyhow if you have time to test booting that would be great. I'll comment back once I commit.

[TheSin-]

commits added, build tested, but again couldn't test boot, let me know.