• Content Count

  • Joined

  • Last visited

About minusdelta

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Not all boards are created equal: OPi+2E Ubnt Xenial Next nightly -> 5.37.171221 = no ethernet; back to 5.34.171121 = OK.
  2. This is empty ATM. Will check my "clean cache" settings and start over. Yes, you are absolutely right. This is much better than my "shoot first, think later" approach. Thanks for appealing to my conscience and your help!
  3. @zador.* thank you very much for your answer, very appreciated! Q3 I was under this impression, too. I searched my build VM and found ... no .deps. Do these show up when changing build options to "KERNEL_ONLY yes" ? Q1 w/ the insights I got from your answer to Q2 it looks like in my case I need to replace the files provided by "linux-image" and "linux-dtb" only, keeping the other updates. So pulling from my old image contents of "/lib/modules/" and "/boot" and replacing will do the job ? @wildcat_paris Many thanks for describing your workflow! Adopted "dpkg-que
  4. v5.12 mentions C1 again, this remembered me to give a short update here. Last thing I planned was to compose a working mainline kernel from pre compiled stuff at kernelci.org. Their config is here, modules and zImage are here, dtb here and rootfs (possibly) here. But as a replacement I had to take my spare C1+ into "production" ad hoc so there is no test platform here at the moment (OPI+2E ordered). Hint: v5.10 mentions but the C1+ isnt, there is no working docker storage driver for it.
  5. On one machine I forgot to "pin" (apt-mark hold) custom kernel pkgs ... and updated :-/ but no reboot yet. This leads to these 3 questions: Q1 How to recover ? Pull from back-up of sd-card image ? What ? Any hints are greatly appreciated as you can imagine. Q2 More generally: which pkgs to pin ? Usually I set linux-image-* and linux-headers-* on hold but this particular update additionally installed newer versions of linux-dtb-next-sunxi:armhf linux-firmware-image-next-sunxi:armhf linux-jessie-root-next-bananapipro:armhf linux-u-boot-bananapipro-next:armhf Does installing these
  6. Aufs4 was easy I meant, for aufs3 I dont think so.
  7. You mean for aufs3 and armbian? Or aufs4 too? (I ask because this is quite simple and well documented.) For aufs3: I will start experimenting after a failing test of device mapper storage driver only ... this route is my current favourite to go for a working docker with c1 and armbian.
  8. . I recompiled and all is fine now. Thanks for checking! I forgot to re-add "CLEAN_LEVEL" after the last upgrade of compile.sh. Regarding 4.x you confirmed my fears. Now I have to find out how to compile aufs3 with armbian or to stick w/ my current OS.
  9. Beside armbian I know 4 images for C1 (Hardkernel official, community eg. Odrobian, hypriot's image-builder-odroid-c1), all 3.10.x. 4.x is mentioned here.
  10. Thank you for looking into it. A propos "old kernel" - will there be a NEXT for C1 ? There are two reasons why I am asking: One is AUFS: with help of your wonderful toolchain I could compile a NEXT for my Banana M1 including AUFS (aufs4), aufs3 is unsupported since Jan 2015 and doesnt compile at 3.10.101. Second, some (IPVlan) of the new docker libnetwork features want 4.2 at least.
  11. First of all many thanks for supporting the Odroid C1! After I noticed the "Final C1 fixes" commit I flashed the C1 image (labeled "Docker ready") and ran the "check-config.sh" from docker. Surprisingly it mentioned some missing items and I found that /proc/config.gz of this image differs from linux-odroidc1-default.config. Booting a self compiled image failed, serial log is here as always ;-)
  12. ... unfortunately not. Serial log is here: https://gist.github.com/minusdelta/7c34e4af5d0d96168028