Add debian stretch image

[zoic21]

Hi, Can you add debian stretch on os choice, I known it's a testing system but I think, in case of test it's googd idea to have it.

Thank for your amazing work.

[herm]

You can just add it to your apt sources and then do a apt-get dist-upgrade.

[jobenvil]

You can just add it to your apt sources and then do a apt-get dist-upgrade.

jep, but why not directly instead of dist-upgrade. Save ttime is a good argument to consider on.

[ThomasKaiser]

add it to your apt sources and then do a apt-get dist-upgrade.

That's the way to go, then please report back with what is working where and what's not. You should keep in mind that Armbian supports a few board families now and also two architectures: armhf and arm64.

As soon as we start to add another distro to our build system people start checking sources out, build images and get back to us with bug reports (wasting our time and preventing us doing something more useful). So the most basic requirement for adding a new distro are reports of upgraded jessie installations on armhf and arm64 :)

But that's not enough since countless tweaks are necessary -- just to give you an idea regarding the last added distro (Xenial Xerus): That's what git log | grep -i xenial spits out:

Serial console fix for Xenial. Tested on H3 and A20 ... with different results but acceptable since this is currenlty the only known way that serial console works in Xenial
Bugfix for preinstall scripts. Manifested in kernel install on Xenial
Xenial to the repository
Fixed motd on Ubuntu(s) - remove legal infos since we are not Ubuntu, enabling unattended upgrades on Xenial.
Bugfix - when building Xenial desktop on Orange Pi legacy 20% overhead is not enought. We don't count the size of kernel, firmware, ...
Upgrading deboostrap to 1.0.78 on Trusty host so also Xenial images builds fine
Merge pull request #303 from bit/xenial
Fix xenial builds
xenial no longer installes python-apt.
run apt-get install -f to configure all packages in xenial
Xenial target related updates
Reenable update-initramfs on Xenial
Remove debconf-utils from debootstrap (fix for Xenial)
SSH root login fix for xenial
Add Xenial to supported build hosts list
Added Ubuntu Xenial Xerus to the menu
Change /etc/network/interfaces only for Xenial target
Refactoring for build-all, added CLI_TARGET to configuration.sh for defining which CLI images we build, same logic as DESKTOP_TARGET, prepared for Ubuntu Xenial
Xenial desktop legacy needs separate code for hardware acceleration support
Small fix for Xenial target
Fix for gksu on Xenial
Disable setserial on Xenial
Fix FEL/NFS boot on Xenial
Fix for Xenial desktop
Temporary fix for Xenial
Disable switching to GCC 4.9 for wily and xenial
Initial support for Xenial build target
Prepare Pine64 addition and Ubuntu Xenial changes

We can use this issue for sure to collect all the problems that need attention when upgrading to or starting to officially support stretch :)

Save ttime is a good argument to consider on

Exactly. So unless upgrade experiences do exist it's just a waste of time thinking about adding a new distro to the build system :)

[zoic21]

I test with change of apt source (sed -i 's/jessie/stretch/g' /etc/apt/sources.list) then dist-upgrade, I juste use mysql/apache/php on my board (odroid C2) and I did see any issue after this upgrade, just initramfs-tools package need to be lock (it's can not update on stretch).

[ThomasKaiser]

Well, if there are zero problems then the next logical step is a simple search&replace and see how things evolve:

(EDIT: Added the 3 cp -p lines and adjusted compile.sh to parameters)

git clone https://github.com/igorpecovnik/lib --depth 1
grep -r -i jessie lib/* | cut -f1 -d: | sort | uniq | while read ; do
    sed -i -e 's/jessie/stretch/g' -e 's/Jessie/Stretch/g' "${REPLY}"
done
cp -p  lib/config/apt/sources.list.jessie lib/config/apt/sources.list.stretch
cp -pr lib/config/polkit-jessie lib/config/polkit-stretch
cp -p lib/bin/jessie-desktop.tgz lib/bin/stretch-desktop.tgz
cp lib/compile.sh .
./compile.sh PROGRESS_DISPLAY=plain RELEASE=stretch BUILD_DESKTOP=no EXTENDED_DEBOOTSTRAP=yes ROOTFS_TYPE=ext4 BRANCH=default COMPRESS_OUTPUTIMAGE=no PROGRESS_LOG_TO_FILE=yes EXTERNAL=no

BUILD_DESKTOP=yes should be considered worst case scenario at least when $LINUXFAMILIY is sunxi so better set this to no for first steps.

[ThomasKaiser]

Next logical step would be to compare our default jessie packages with the stuff dist-upgrade changed (/var/log/apt/history.log?), to correct that and try again. Then check the problems when booting such an image (serial console is a requirement), try incrementally to improve this stuff and in case you write a proper installation log this will help adding support for stretch enormously! :)

[ThomasKaiser]

BUILD_DESKTOP=yes is a stretch showstopper as is EXTERNAL=yes (default). I let the aforementioned search/replace build ran for an armhf board to see what will fail: http://kaiser-edv.de/tmp/emoRSK/

In other words: lots of work to do :)

[zador-blood-stained]

[ o.k. ] Extracting stretch-ng-armhf.993...e7f.tgz [ 0 days old ]
stretch-ng-armhf.993...e7f.tgz: 95,6MiB [94,2MiB/s] [======================================================>] 100%

95.6MB - too low for cached rootfs, there were problems in previous build (probably missing packages?)

[zador-blood-stained]

As soon as we start to add another distro to our build system people start checking sources out, build images and get back to us with bug reports (wasting our time and preventing us doing something more useful). So the most basic requirement for adding a new distro are reports of upgraded jessie installations on armhf and arm64 :)

I agree. Just build a Jessie image and dist-upgrade it to Stretch. Right now I don't see any reasons to officially prepare Stretch support if it only will be used by less than 10% of our users.

[ThomasKaiser]

95.6MB - too low for cached rootfs, there were problems in previous build (probably missing packages?)

Yeah, it broke two times before since I tried out both BUILD_DESKTOP=yes and EXTERNAL=yes. New try, same result: http://kaiser-edv.de/tmp/1Q0LLM/

@zoic21 / @jobenvil and that's the problem: it requires a lot of work to add another distro variant (especially when there's still much WiP), then as soon as we added that other distro everything has to be tested with this variant too so until stretch will be the stable release we will waste several developer _days_ for nothing.

So please feel free to take this as an excercise (helps understanding Armbian's build system a lot), create a proper installation/change log to be used later but please drop the idea to add stretch support now to the build system. :)

[zador-blood-stained]

From https://wiki.debian.org/DebianStretch

• 2016-11-05: Transition freeze (general freeze of transitions)
• 2017-01-05: "Soft" freeze (no new packages, no re-entry, normal migrations)
• 2017-02-05: Full freeze

After full freeze it will be safe enough to add Stretch support with fixed package lists in configuration.sh

Edit:

cp: cannot stat '/var/git/stretch/lib/config/apt/sources.list.stretch': No such file or directory

This should be created with proper contents

[ThomasKaiser]

This should be created with proper contents

Will look into it... in exactly 8 months :)

[jobenvil]

@zoic21 / @jobenvil and that's the problem: it requires a lot of work to add another distro variant (especially when there's still much WiP), then as soon as we added that other distro everything has to be tested with this variant too so until stretch will be the stable release we will waste several developer days for nothing.

Thanks for the explanation, I see now, it's not trivial work.

[ThomasKaiser]

Thanks for the explanation, I see now, it's not trivial work.

But that's only one aspect. The other is: When we add a new distro that's still WiP then the following might happen: We define the list of default packages for this distro, then distro maintainers decide to rename a package. In the meantime a new dev starts to use Armbian trying to improve something in a totally different area. And all his builds breake since he's using stretch.

Even more worse: The build does not break but succeeds but then one of the commands provided by one of the packages isn't available and eg our firstrun script relies on that (and we've still not the best error handling in most of our scripts): Then even data loss might occur.

Therefore adding a new distro to the build system is only worth the efforts when it's already stable and we also decide to spend the necessary ressources on testing every stuff on every distro supported (already much more efforts since we added Xenial)