Jump to content

Debian Stretch Porting and Optimizations

edolnx

By edolnx
in Advanced users - Development

 Share

Recommended Posts

edolnx

edolnx

Posted
Posted

The topic of Stretch came up in the Odroid C2 Mainline testing thread, and turns out we don't have a thread about making Stretch available. I've done some testing with several boards using the Upgrading Debian Jessie to Stretch thread and had great success. But, I wanted to start a discussion about what is needed to get official Stretch support in place. I have several projects where I need to use Stretch instead of Jessie, so I'm exited to help try and contribute where I can.

 

I also wanted to discuss the idea of possibly making two stretch images: one using systemd and one using openrc (which is supported in Stretch). 99% of the work is identical, the only major changes are needing to patch /etc/inittab to enable a serial console for the openrc version and not installing systemd :)

 

I have several Odroid C1+ and C2 boards I can test on, as well as some pcDuino 3 Nano boards. I also have some Rockchip based boards I'm hoping to contribute support for (RK3368 based Geekbox, and a RK3399 based Firefly) but I think I'll need Stretch for the Firefly board.

 

So, is there a TODO list somewhere I have not found? If not, can we make one here or a tag for issues in GitHub so we can start tackling them?

zador.blood.stained

zador.blood.stained

Posted
Posted
5 hours ago, edolnx said:

So, is there a TODO list somewhere I have not found?

No, at least not a public one. Current TODO list would look like this: 

[x] Add initial Stretch support - menu entries, packages, tweaks
[x] Disallow building Stretch images for kernels < 3.13
[ ] Solve problems with additional packages (EXTERNAL_NEW)
[ ] Check and update dependencies for packages like tools and firmware
[ ] Update LIRC config file path
[ ] Check if any common tweaks need adjustments
[ ] Build and test Stretch images
[ ] Build and push packages to the Stretch section of the repository

 

5 hours ago, edolnx said:

I also wanted to discuss the idea of possibly making two stretch images: one using systemd and one using openrc (which is supported in Stretch). 99% of the work is identical, the only major changes are needing to patch /etc/inittab to enable a serial console for the openrc version and not installing systemd :)

Same as migrating Jessie images to sysvinit. If this can be done by end users from a running system (and I don't see why not) - leave this up to end users. We have a lot of systemctl calls (including "systemctl mask" which doesn't have an analog for update-rc.d) in the build script and I'm not a fan of adding a lot of conditions/wrappers for different init systems.

edolnx

edolnx

Posted
  • Author
Posted
On 8/2/2017 at 8:33 AM, zador.blood.stained said:

No, at least not a public one. Current TODO list would look like this: 


[x] Add initial Stretch support - menu entries, packages, tweaks
[x] Disallow building Stretch images for kernels < 3.13
[ ] Solve problems with additional packages (EXTERNAL_NEW)
[ ] Check and update dependencies for packages like tools and firmware
[ ] Update LIRC config file path
[ ] Check if any common tweaks need adjustments
[ ] Build and test Stretch images
[ ] Build and push packages to the Stretch section of the repository

 

Same as migrating Jessie images to sysvinit. If this can be done by end users from a running system (and I don't see why not) - leave this up to end users. We have a lot of systemctl calls (including "systemctl mask" which doesn't have an analog for update-rc.d) in the build script and I'm not a fan of adding a lot of conditions/wrappers for different init systems.

 

Understood on the systemd vs openrc request. It makes sense, I just wanted to get some feedback on the idea.

 

Could you describe more about what "Solve Problems with additional packages (EXTERNAL_NEW)" means? Are these packages added my Armbian or something else? I'm still trying to learn all the nomenclature and design decisions in the existing codebase...

martinayotte

martinayotte

Posted
Posted

BTW, I tried my first Stretch build this afternoon, but it failed on some apt-get dependencies, therefore the image was unusable due to missing uInitrd :

  

You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 armbian-tools-stretch : Depends: libusb-1.0-0 (>= 2:1.0.8) but it is not going to be installed
                         Depends: libusb-0.1-4 but it is not going to be installed
 hostapd : Depends: libnl-3-200 (>= 3.2.7) but it is not going to be installed
           Depends: libnl-genl-3-200 (>= 3.2.7) but it is not going to be installed
           Depends: libnl-route-3-200 (>= 3.2.7) but it is not going to be installed
 linux-stretch-root-dev-pine64 : Depends: linux-base but it is not going to be installed
                                 Depends: u-boot-tools but it is not going to be installed
                                 Depends: initramfs-tools but it is not going to be installed
 sunxi-tools : Depends: libusb-1.0-0 (>= 2:1.0.16) but it is not going to be installed

 

Hugo Cardozo

Hugo Cardozo

Posted
Posted

Now I'm using Stretch on most of my boards, and I want to share my experiences.

First, some pointers:

  1. All my boards are headless servers of some sort (routers, gateways, WAPs, NASes...). I didn't try desktop, video, xorg, anything with graphics
  2. When available, I use mainline kernel, be it "next", "dev", or "roll-your-own" through armbian toolchain

The boards which are currently running Stretch are:

  • Orange Pi PC
  • Banana Pi M1
  • Cubieboard 2

Now I'm trying to upgrade my Odroid-C2 to Stretch and mainline, but so far I didn't succeed. As I do not get any output on HDMI nor serial (beyond "Starting kernel..."), I don't know what's wrong... We'll see

zador.blood.stained

zador.blood.stained

Posted
Posted
19 hours ago, martinayotte said:

the image was unusable due to missing uInitrd

Please make sure that files in packages/common/bsp keep their attributes from git (i.e. etc/initramfs/post-update.d/99-uboot should be executable)

martinayotte

martinayotte

Posted
Posted

Ok ! I've built successfully the Pine64 Stretch image from another Desktop !

I will have to narrow why the other one didn't while been able to do a Jessie image without issues ...

 

Hugo Cardozo

Hugo Cardozo

Posted
Posted
On 8/8/2017 at 9:18 AM, Hugo Cardozo said:

Now I'm using Stretch on most of my boards, and I want to share my experiences.

First, some pointers:

  1. All my boards are headless servers of some sort (routers, gateways, WAPs, NASes...). I didn't try desktop, video, xorg, anything with graphics
  2. When available, I use mainline kernel, be it "next", "dev", or "roll-your-own" through armbian toolchain

The boards which are currently running Stretch are:

  • Orange Pi PC
  • Banana Pi M1
  • Cubieboard 2

Now I'm trying to upgrade my Odroid-C2 to Stretch and mainline, but so far I didn't succeed. As I do not get any output on HDMI nor serial (beyond "Starting kernel..."), I don't know what's wrong... We'll see

 

WTF...! That's all I can say.

 

Yesterday I've found balbes' instructions for debugging odroid boot (setting ' setenv verbosity "7" ' on boot.ini), and today I've tried again to upgrade to Stretch and install a custom kernel. And it all worked flawlessly! The only thing I've changed was the "verbosity" bit... Anyway,  now my Odroid-C2 runs Stretch too.

Igor

Igor

Posted
Posted

When building Stretch desktop it always stuck here. I tried with and without apt-cacher.

  

Unpacking libntfs-3g871 (1:2016.2.22AR.1+dfsg-1) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-wi5pLa/079-gnome-icon-theme_3.12.0-2_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

 

If I install desktop natively it works ok. Any ideas?

TonyMac32

TonyMac32

Posted
Posted

For curiosity I built Stretch for the Tinker Board a week or so ago, it worked then.  Let me try it again and see/share the results.

Igor

Igor

Posted
Posted

CLI works for me fine (except LIRC errors), but desktop building always stuck there. Little before I found:  

Unpacking librsvg2-common:armhf (2.40.16-1+b1) ...
Selecting previously unselected package gnome-icon-theme.
Preparing to unpack .../079-gnome-icon-theme_3.12.0-2_all.deb ...
Unpacking gnome-icon-theme (3.12.0-2) ...
dpkg: error processing archive /tmp/apt-dpkg-install-wi5pLa/079-gnome-icon-theme_3.12.0-2_all.deb (--unpack):
 corrupted filesystem tarfile - corrupted package archive
Selecting previously unselected package adwaita-icon-theme.
Preparing to unpack .../080-adwaita-icon-theme_3.22.0-1+deb9u1_all.deb ...
Unpacking adwaita-icon-theme (3.22.0-1+deb9u1) ...

I already removed the file from apt-cacher, disable cache by adding NO_APT_CACHER=yes to userpatches/lib.config ...

zador.blood.stained

zador.blood.stained

Posted
Posted
4 minutes ago, Igor said:

dpkg: error processing archive /tmp/apt-dpkg-install-wi5pLa/079-gnome-icon-theme_3.12.0-2_all.deb (--unpack): corrupted filesystem tarfile - corrupted package archive

It may actually be corrupted in the (auto)selected Debian mirror, I had similar issues sometimes when using local Debian mirrors.

Igor

Igor

Posted
Posted
4 hours ago, zador.blood.stained said:

It may actually be corrupted in the (auto)selected Debian mirror, I had similar issues sometimes when using local Debian mirrors.


Forced switch to US or DE mirror, with cleaned apt-cacher or without it always failed here. Getting crazy :( Out of ideas for today.

Igor

Igor

Posted
Posted

It unpacks without any complains ... will try in chroot too.

Igor

Igor

Posted
Posted

I could easily reproduce the problem on a notebook than I restarted building once again on a server and it works now. Running Stretch on Banana Pi now (btw. there is regression in its u-boot: no hdmi out)

 

debianxfce

debianxfce

Posted
Posted
18 hours ago, Igor said:

When building Stretch desktop it always stuck here. I tried with and without apt-cacher.

  


Unpacking libntfs-3g871 (1:2016.2.22AR.1+dfsg-1) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-wi5pLa/079-gnome-icon-theme_3.12.0-2_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

 

If I install desktop natively it works ok. Any ideas?

I had that too. If I remember correctly the space in my system partition was running out. Doubling the system partition size fixed the problem.

Igor

Igor

Posted
Posted
2 minutes ago, debianxfce said:

I had that too. If I remember correctly the space in my system partition was running out. Doubling the system partition size fixed the problem.


It could be in my case too. At around 95% I still had around 15G of free space, notebook drive is anyway on the limit all the time since its small ... strange.

1
debianxfce

debianxfce

Posted
Posted
6 minutes ago, Igor said:


It could be in my case too. At around 95% I still had around 15G of free space, notebook drive is anyway on the limit all the time since its small ... strange.

My desktop pc has a 240GB SSD and I can  build my Debian testing Xfce Amlogic S912 distribution successfully with the this disk layout:

xfce@carrizo:~$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
udev             4058272         0   4058272   0% /dev
tmpfs             812256      9128    803128   2% /run
/dev/sda1       30747364  13242328  15920196  46% /
tmpfs            4061280     76328   3984952   2% /dev/shm
tmpfs               5120         4      5116   1% /run/lock
tmpfs            4061280         0   4061280   0% /sys/fs/cgroup
/dev/sda5      199740488 150834480  46859052  77% /home
tmpfs             812256         4    812252   1% /run/user/1000
 

This is my command line:

xfce@carrizo:~$ ./compile.sh BOARD=amlogic-s912 PROGRESS_DISPLAY=plain RELEASE=testing PROGRESS_LOG_TO_FILE=yes KERNEL_ONLY=no BUILD_DESKTOP=yes BRANCH=next CLEAN_LEVEL=debs NO_APT_CACHER=yes
 

zador.blood.stained

zador.blood.stained

Posted
Posted
6 minutes ago, debianxfce said:

My desktop pc has a 240GB SSD and I can  build my Debian testing Xfce Amlogic S912 distribution successfully with the this disk layout

Disk layout doesn't matter much because for the debootstrap a tmpfs mount is used, so RAM size here matters (tmpfs mount size by default is set to 2/3 of physical RAM size)

 

8 minutes ago, debianxfce said:

./compile.sh BOARD=amlogic-s912 PROGRESS_DISPLAY=plain RELEASE=testing PROGRESS_LOG_TO_FILE=yes KERNEL_ONLY=no BUILD_DESKTOP=yes BRANCH=next CLEAN_LEVEL=debs NO_APT_CACHER=yes

This is definitely not the main repository (github.com/armbian/build) so it isn't exactly correct to extend behavior of the fork to the main repo/branch.

debianxfce

debianxfce

Posted
Posted
9 minutes ago, zador.blood.stained said:

Disk layout doesn't matter much because for the debootstrap a tmpfs mount is used, so RAM size here matters (tmpfs mount size by default is set to 2/3 of physical RAM size)

 

This is definitely not the main repository (github.com/armbian/build) so it isn't exactly correct to extend behavior of the fork to the main repo/branch.

 

In my case, increasing system partition size that error message dissappeared.  I did wrote:  my Debian testing Xfce Amlogic S912 distribution. Of course sources are heavily tweaked. There is no support for S912 and Debian testing in armbian., my work is based on balbes150 work

Naguissa

Naguissa

Posted
Posted

It could be in my case too. At around 95% I still had around 15G of free space, notebook drive is anyway on the limit all the time since its small ... strange.



Be cautious, specially if you use btrfs, you can be out of inodes with that hight fs usage.

Enviado desde mi Jolla mediante Tapatalk

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept