Jump to content

Debian Stretch Porting and Optimizations

edolnx

By edolnx
in Advanced users - Development

 Share

Recommended Posts

Igor

Igor

Posted
Posted
14 minutes ago, ZupoLlask said:

Hi guys! 

 

How far are we from next release to be Stretch based? 

 

What needs to be done? 

 

Is anyone coordinating those efforts? 

 

Is this a priority? 


Basic things are working but it's not very much tested. I remember two bugs that are out there and haven't been fixed yet:

 

- LIRC Configuration

- our custom build hostapd does not want to install or fails to work. We won't use upstream version


Nobody is coordinating this and help is needed otherwise this will take some time ...

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

Regarding building additional packages for Stretch - I tested some initial changes today, but it will need some work: 

[ warn ] Following packages failed to build:
[ .... ] xf86-video-fbturbo:stretch:armhf
[ .... ] fswebcam-gc2035:stretch:armhf
[ .... ] guvcview:stretch:armhf
[ .... ] hostapd:stretch:armhf
[ .... ] hostapd-realtek:stretch:armhf
[ .... ] libmali-sunxi-r3p0:stretch:armhf
[ .... ] sunxi-tools:stretch:armhf
[ .... ] swconfig:stretch:armhf
[ .... ] xf86-video-fbturbo:stretch:arm64
[ .... ] hostapd:stretch:arm64
[ .... ] hostapd-realtek:stretch:arm64
[ .... ] sunxi-tools:stretch:arm64

 

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
Just now, zador.blood.stained said:

We could also try to adapt the upstream 2.5 version, at least for the non-realtek variant.


How do you mean? To not make on our own? 

 

Changing this https://github.com/armbian/build/blob/master/packages/extras-buildpkgs/90-hostapd.conf#L4-L5 to 2.6 should do the trick? I have no proper/better idea.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted
5 minutes ago, Igor said:

Changing this https://github.com/armbian/build/blob/master/packages/extras-buildpkgs/90-hostapd.conf#L4-L5 to 2.6 should do the trick? I have no proper/better idea.

Right now we should set 

local package_upstream_version="2:2.5"

In the future we can try to use upstream 2.6, but it will require adjusting some patches.

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

This adjust source version while package remains the same.

 

Source: wpa (2.5~armbian5.33.170922+1)
Version: 1:2.5~armbian5.33.170922+1 

 

Source: wpa (2:2.5~armbian5.33.170925+1)
Version: 1:2.5~armbian5.33.170925+1

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

Another bug. Haven't pinpointed yet but it most likely comes from upstream. Wireless connection (using nmtui-connect) timeouts on initial connect very often, while the exact same setup works perfectly fine on Ubuntu Xenial. When setting up an AP it works fine.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted
15 hours ago, Igor said:

Wireless connection (using nmtui-connect) timeouts on initial connect very often, while the exact same setup works perfectly fine on Ubuntu Xenial. When setting up an AP it works fine.

Can it be related to the random MAC address "feature"? https://github.com/armbian/build/issues/741#issuecomment-332072152

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted
44 minutes ago, Igor said:

Shall we add this by default?

 

I'm really not sure since MAC address randomization should be considered an essential feature these days especially when we think about supporting devices like PineBook. At least I would suggest to first check whether stopping device renaming isn't the better option as described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839605#25

 

Does this apply to Stretch too?

Link to comment
Share on other sites
tkaiser

tkaiser

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

We can always override settings by adding another file specifically for the Pinebook.

 

And then reverting the additional NM defaults change back? Also individually for the Pinebook?

 

As far as I understood the 'problems' are

  • nmtui connect problem reported by Igor (most probably since NM changing MAC address in between call of nmtui and trying to establish connection?)
  • According to the github issue syslog spamming (which I consider not being a problem since 'attaching to a network seems to have stopped the noise as well')
  • According to the same github issue 'NetworkManager is keeping the CPU busy'. Does this change after stopping MAC address randomization? Is NM silent now or is it still busy bot now with the same MAC address?

Adding to the above I wonder what's the state of affairs wrt Wi-Fi powermanagement and NM in Stretch (since dmesg output on Github seems to indicate it's not working as on Jessie or Xenial).

 

I haven't looked into this myself but to me the issues that should been looked at a little bit closer wrt Stretch are

  • powermanagement settings
  • constant try to search for networks (how to disable this would be my first question)
  • nmtui-connect problems (if we can stop NM from permanently searching for open Wi-Fis on its own is this still an issue then?)

Adopting a workaround that's 'recommended' by countless Debian/Ubuntu users reminds of the 'UAS is evil' stupidity mess we have to deal with in the Linux world.

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted
2 hours ago, Igor said:

Shall we add this by default?

 

Hmm... by looking around I came accross this (which doesn't seem to make sense to me but is reported to work) 

[device-mac-randomization]
wifi.scan-rand-mac-address=no

[connection-mac-randomization]
ethernet.cloned-mac-address=random
wifi.cloned-mac-address=random

And then when reading about NM doing a Wi-Fi background scan every 120 seconds by default (can be disabled by locking the BSSID to the profile) and problems with some Wi-Fi driver this reminded me of the reported Wi-Fi reliability issues we had (only when connecting with NM/nmtui/nmcli and not happening when establishing Wi-Fi 'the traditional way'). Since I can't remember whether this occured with all sorts of drivers or only with one (eg. 8189fs for example?) may I ask whether someone else remembers? Just to decide with which board to further test...

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

I noticed problems with external adapters first. There are not many working ones and if those working ones are further crippled by this feature, there are no woking left :) 

 

Well, let's do some more tests.

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted
14 minutes ago, Igor said:

http://sprunge.us/MLdL

 

Hehe... this is your setup with 40 Wi-Fi USB devices connected? ;)

 

Yeah, setting connection-mac-randomization to random doesn't make much sense. And still not knowing with which device to test first (since trying to keep it simple first with only one available Wi-Fi device connected, preferrable onboard)

Link to comment
Share on other sites
chymian

chymian

Posted
Posted

may I chime in with my latest experiences on self-build stretch images for the XU4/HC1:
in stretch, the former eth0 get renamed to enx001e0630cdfb (on the XU4), and surly to other names on other HW.

that does not happen when upgraded from jessie.

see also: https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names


that leads to:
1. the default /etc/network/interface config with 'eth0 dhcp' does work here somehow – but it shouldn't. don't know for other HW.

2. but setting up an bridge br0 with eth0 as interface does not work. it needs the new interface name.

 

so it seems a little bit random and might leave one with an unreachable device.


suggestion:
adapt all /etc/network/interface* files with an automatic script at firstboot to the interface-name the kernel uses (i.e. in /proc/net/dev)

somthing like this should do it: 

IFNAME=`grep en /proc/net/dev|cut -d: -f1`
or
IFNAME=`basename $(ls -d /sys/class/net/en*)`

sed -i s/eth0/$IFNAME/g /etc/network/interfaces*

same applies to wlan-interfaces

Link to comment
Share on other sites
chymian

chymian

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

It should take care of this already, that's why renamed interfaces "magically" work

so it was NM who gave the HC1 the dhcp-ip on the "enx001e0630cdfb"-interface, not the ifupdown-scripts.  makes sense.
and why was it not reachable after I added a bridge-config to interfaces (with eth0), not touching NM. that shouldn't have touched the NM setup of  "enx001e0630cdfb" - right?
tracing the traffic shows, that both, the fixed bridge-ip (eth0) and the NM-dhcp-ip (enx001e0630cdfb) responds to arp-packages, but not to ping or ssh.

it seems to be buggy and leads to inconsistent behavior.


so, relaying on NM would also mean removing /etc/network/interfaces and at least add a BFW to the other interfaces.*-files about the changed name, to make it less confusing.

 

it left me with an headless server (HC1) which was not net-reachable.
and for an server-like device, I experienced over the years, is an fixed config much more reliable then NM.
just my 2cent

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted
25 minutes ago, chymian said:

and for an server-like device, I experienced over the years, is an fixed config much more reliable then NM.

I kind of agree with this, but as long as the device has only one Ethernet port, no wireless devices and disabled "predictable interface names". Since we started to attract a lot of inexperienced users when we added support for cheap H3 boards it was decided to install NM by default on all images (both server and desktop) so inexperienced users could benefit from it, and advanced users can always disable/remove/customize stuff as they want.

Link to comment
Share on other sites
botfap

botfap

Posted
Posted

I thought I had a LOT of problems with NetworkManager on stretch, xenial & artful (arm+x64 but not Armbian):

  • Unreliable connections on the WiFi side
  • Interfaces that magically shut down with no log on the wired side
  • MAC address randomisation mid way through setting up a wifi connection causing the connection to fail to negotiate (realtek & ralink in particular)
  • Network device names changing between boot (not strictly NM but related)
  • PPTP interfaces not coming up automatically
  • NM wiping out custom bridge configs, etc

I found that the problem was not actually NetworkManager in most cases but caused by inconsistencies (polite description) in systemd behaviour. The only problem that was down to NM was the point at which it randomises MAC addresses when negotiating a wifi connection. The other problems were down to systemd / udev fucking with device names, not just at boot but in response to changes in network device status. Devices disappear for a few seconds instead of just changing status.

 

Easy way to fix the randomisation problem is disable it, but it shouldn't be a huge issue to re-sequence NM code to randomise before it scans not after.

The device names problems can be fixed with "net.ifnames=1 biosdevname=0" on your boot args which switches back to old style naming conventions for devices.

Link to comment
Share on other sites
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