Debian Stretch Porting and Optimizations

[zador.blood.stained]

7 minutes ago, botfap said:

The only problem that was down to NM was the point at which it randomises MAC addresses when negotiating a wifi connection.

This was discussed already, it causes a lot of problems and most likely will be disabled by a config drop-in in the Armbian board support packages.

 

9 minutes ago, botfap said:

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.

This should not happen unless udev for some reason picked random MAC addresses set by NM each time, and disabling this NM "feature" should fix this too.

[botfap]

46 minutes ago, zador.blood.stained said:

This was discussed already, it causes a lot of problems and most likely will be disabled by a config drop-in in the Armbian board support packages.

I know, thats why Im providing the info I found. But I think that for chromebook / armbook users particularly mac randomisation is pretty useful feature. You can keep that feature by disabling background scans (not useful once connected) and switching the SSID scanning to passive which doesn't even need a mac address.

 

46 minutes ago, zador.blood.stained said:

This should not happen unless udev for some reason picked random MAC addresses set by NM each time, and disabling this NM "feature" should fix this too.

If it should or shouldn't is debatable but the fact it that it does. On arm and intel, on stretch, xenial & artful and others. Add "net.ifnames=1 biosdevname=0" to switch back to old style naming will stop the connections dropping while in use and getting messed up between reboots. Or do it properly and add a new .link profile for systemd.

 

 

[tkaiser]

8 hours ago, botfap said:

Add "net.ifnames=1 biosdevname=0" to switch back to old style naming will stop the connections dropping while in use and getting messed up between reboots

 

Sounds like the better approach to me than choosing the first ugly workaround 'recommended' by Ubuntu/Debian community members. What are the possible downsides of switching back to the old naming scheme (long time Armbian users want to keep anyway)?

[botfap]

44 minutes ago, tkaiser said:

 

Sounds like the better approach to me than choosing the first ugly workaround 'recommended' by Ubuntu/Debian community members. What are the possible downsides of switching back to the old naming scheme (long time Armbian users want to keep anyway)?

Downsides are that if you have multiple interfaces of the same type its possible (but unlikely) that they can swap device names under a very limited set of circumstances.

 

e.g. You have 2 x usb wifi dongles which use the same driver plugged in and configured on USB ports 1 & 2 and interfaces wlan0 & wlan1. If you unplug the devices and plug them back in with the usb ports swapped over then device 1 could POSSIBLY swap to wlan1 and device 2 will swap to wlan0. For 99% of circumstances this doesn't matter and doesn't get noticed by the end user because the same 2 connections still exist and connect.

 

For multiple wired connections on usb it can be more problematic because usually you want a specific interface connecting to a specific switch port or gateway. if you then swap them over your network isnt going to function as expected.

 

The other circumstance where they can change is when you install a new kernel / modules with a very different config which causes the drivers to load in a different order. The first driver loaded obviously grabs eth0 or wlan0 so if a driver is moved from kernel to module or vice versa it can swap the device names, even if the interfaces connect using different busses.

 

They are all very edge case scenarios for unusual hardware configs though. I can sympathise with the reasoning behind the new device names change but for embedded systems, where the config and hardware is generally pre-defined it adds a lot of complexity and instability for zero improvement in manageability. 

 

Im sure the situation will improve in buster / 18.04, there have been a lot of changes in userland over the last couple of years (systemd, NM, eudev changes, etc) and they dont all seem to work together fully yet. I build our companies embedded systems without NM & systemd and use old style device naming on buildroot based platform. I would love to be able to swap to something like Armbian for the less critical devices but the support overhead that it adds out in the field is substantial. 

[zador.blood.stained]

1 hour ago, tkaiser said:

Sounds like the better approach to me than choosing the first ugly workaround 'recommended' by Ubuntu/Debian community members.

Why? This disabled predictable network device names, but we are also talking about MAC address randomization which is IMO only useful for portable devices (so only for the Pinebook)

 

12 minutes ago, botfap said:

They are all very edge case scenarios for unusual hardware configs though. I can sympathise with the reasoning behind the new device names change but for embedded systems, where the config and hardware is generally pre-defined it adds a lot of complexity and instability for zero improvement in manageability. 

"Predictable names" were added mostly for USB (and PCI/PCIe) devices so you could plug them in any port at any time and would get a permanent MAC address based device name, so yes, it's not very useful for SDIO and memory-mapped devices, but I wouldn't jump to "zero improvement" and "lot of complexity" conclusions straight away.

If we disable this, IMO it's better to do it with an udev rule than with kernel command line modification.

[botfap]

27 minutes ago, zador.blood.stained said:

Why? This disabled predictable network device names, but we are also talking about MAC address randomization which is IMO only useful for portable devices (so only for the Pinebook)

 

"Predictable names" were added mostly for USB (and PCI/PCIe) devices so you could plug them in any port at any time and would get a permanent MAC address based device name, so yes, it's not very useful for SDIO and memory-mapped devices, but I wouldn't jump to "zero improvement" and "lot of complexity" conclusions straight away.

If we disable this, IMO it's better to do it with an udev rule than with kernel command line modification.

I didnt jump to it straight away. I slowly came to that conclusion after many years of being messed about by systemd/udev since version 197 ish in 2012. I have literally zero improvement in any of my embedded, server or desktop systems at the expense of a lot of added complexity from systemd/udev combo. Same goes for my engineers and most colleagues I work with at other companies.  If you can give me some real world examples of where it improves things without adding complexity & reliability and troubleshooting issues, then I would be happy to reconsider. Ive been working with embedded unix variants for security devices since 1993 and systemd is the biggest regression in manageability and reliability I have ever seen. Its too big, attempts to do to much, doesn't do what its supposed to do properly and gets new stuff added before old stuff is fixed. This isnt specific to systemd, its a character trait of pretty much everything that comes from the Redhat / Lennart Poettering team including the PulseAudio mess.

 

I do agree however that the correct way to disable "(un)predictable names" devices is via a systemd/udev .link profile or straight udev disable I was just giving you a quick and easy way to test via boot args then you can make your own decisions.

[Igor]

Installing this deb on Stretch:

https://github.com/armbian/build/blob/master/packages/blobs/desktop/vibrancy-colors_2.4-trusty-Noobslab.com_all.deb

this way:

https://github.com/armbian/build/blob/master/lib/image-helpers.sh#L125

results to:

dpkg: error processing archive /root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb (--install):
 corrupted filesystem tarfile - corrupted package archive
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb

Can't find any smart solution.

[botfap]

1 hour ago, Igor said:

Installing this deb on Stretch:

https://github.com/armbian/build/blob/master/packages/blobs/desktop/vibrancy-colors_2.4-trusty-Noobslab.com_all.deb

this way:

https://github.com/armbian/build/blob/master/lib/image-helpers.sh#L125

results to:

dpkg: error processing archive /root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb (--install):
 corrupted filesystem tarfile - corrupted package archive
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb

Can't find any smart solution.

Thats not a valid deb archive. what is the size of it? Is the local file you downloaded 24MB or 39KB?

 

Its the message you would get if Github gave you the html instead of the raw or if the deb was genuinely corrupt.

[Igor]

Its a proper 24mb .deb file. I suspect issue within chroot. Native install works.

Wrote on mobile

[botfap]

2 minutes ago, Igor said:

Its a proper 24mb .deb file. I suspect issue within chroot. Native install works.

Wrote on mobile
 

 

I have had a few github errors tonight where it has returned html instead of raw. Its killed a few of my build in the last 6 hours. When you try and grab it again you get the correct raw returned but occasionally it then spits another html. 

[tkaiser]

On 2.10.2017 at 10:42 AM, zador.blood.stained said:

This disabled predictable network device names, but we are also talking about MAC address randomization which is IMO only useful for portable devices (so only for the Pinebook)

After doing some research I came to the conclusion that blindly trusting in MAC address randomization working as expected isn't a good idea, that I lack time and will to test whether Pinebook really does it correctly and that we can't 'prevent' predictable network device names anyway (eg. Debian declares the old scheme deprecated in version 9 and not available any more in 10). So I'm fine with the proposed fix.

[Igor]

On 2. 10. 2017 at 12:19 AM, zador.blood.stained said:

This was discussed already, it causes a lot of problems and most likely will be disabled by a config drop-in in the Armbian board support packages.

This bug is gone with recent upstream fixes but we got another problem. When you connect with network manager it doesn't show it's connected (nmtui-connect) and BTW we have a kernel bug which prevents connecting all my USB wireless adaptors at once  Even without connecting anything, this is in the logs:

[    4.765206] sy8106a_regulator: section 3 reloc 5 sym 'memset': relocation 10 out of range (0xbf800040 -> 0xc0830be1)
[    4.850498] pwrseq_simple: section 3 reloc 12 sym 'usleep_range': relocation 10 out of range (0xbf8080d2 -> 0xc08432dd)
[    5.901394] x_tables: section 3 reloc 6 sym 'mutex_lock': relocation 10 out of range (0xbf8100fc -> 0xc0842499)
[    6.673396] 8189fs: section 3 reloc 30 sym '_raw_spin_lock_irqsave': relocation 10 out of range (0xbf81b18e -> 0xc0843fa1)

http://sprunge.us/fJIi

[zador.blood.stained]

2 hours ago, Igor said:

This bug is gone with recent upstream fixes but we got another problem.

Are you sure? I don't see any changes in the stretch network-manager changelog

 

2 hours ago, Igor said:

[ 4.765206] sy8106a_regulator: section 3 reloc 5 sym 'memset': relocation 10 out of range (0xbf800040 -> 0xc0830be1)

I may have found a kernel option that may fix that, will commit changes soon

[Igor]

Not 100% sure but i made a test image today and could connect to AP few times. It still acts weird since nm doesnt register that connection was made.

Wrote on mobile

[zador.blood.stained]

This (and similar relocation related issue on XU4/HC1 which killed UAS) should be hopefully fixed. Other kernel configs may have to be changed too in the future.

[Igor]

2 hours ago, zador.blood.stained said:

and similar relocation related issue on XU4/HC1 which killed UAS

 I am just about to try on OPi PC+ ... you mean this issue? 

 

[zador.blood.stained]

4 minutes ago, Igor said:

you mean this issue? 

Rather this one: https://forum.armbian.com/index.php?/topic/5413-odroid-hc1-sata-install/&do=findComment&comment=41281

 

[Igor]

3 hours ago, zador.blood.stained said:

should be hopefully fixed

After few tests everything is fine.

[inos]

I have built a rock64 stretch image and found in syslog:

localhost cron[757]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates)

could be fixed with:

sudo chmod 644 /etc/cron.d/armbian-updates

 

[Igor]

On 3. 10. 2017 at 9:02 PM, Igor said:

Installing this deb on Stretch:

https://github.com/armbian/build/blob/master/packages/blobs/desktop/vibrancy-colors_2.4-trusty-Noobslab.com_all.deb

this way:

https://github.com/armbian/build/blob/master/lib/image-helpers.sh#L125

results to:

dpkg: error processing archive /root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb (--install):
 corrupted filesystem tarfile - corrupted package archive
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb

Can't find any smart solution.

I wasted hours on this problem today and no success.

- I repacked package with no compression, xz, gzip, ...  you name it.

- I tried changing max open files inside a chroot https://lists.debian.org/debian-user/2010/09/msg01318.html

- deb package has little more than 25000 files with links. If I repack it with just "a little file" ... it works.

- it looks its related to a number of files since the same file size .deb pack installs normally

Any clue?

[tkaiser]

Have you compared 'ulimit -n' on your host and running inside chroot?

[Igor]

Yes. Even set the same, no impact

[Igor]

1st possible dirty workaround:

cp $SRC/packages/blobs/desktop/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb $SDCARD/root/
chroot $SDCARD /bin/bash -c "dpkg -x /root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb /"
rm $SDCARD/root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb

 

[tkaiser]

Anyone already tried nand-sata-install with Stretch? I did before and it seems

DEST=$(df -BM | grep ^/dev | grep ${TempDir}/rootfs | awk '{print $4}' | tr -cd '[0-9]. \n')

failed since ${TempDir}/rootfs wasn't mounted at this stage (sorry, I wiped already the installation out, accidentally closed the Terminal Windows and didn't had a 2nd look).

[Igor]

Another Stretch problem. When using BT, this pops out:
 

[zador.blood.stained]

12 minutes ago, Igor said:

Another Stretch problem. When using BT, this pops out:

Possibly we need more policykit rules to fix this. But in any case I don't think we should make any prebuilt Stretch desktop images yet, especially if this delays the stable release.

[Igor]

3 minutes ago, zador.blood.stained said:

Possibly we need more policykit rules to fix this. But in any case I don't think we should make any prebuilt Stretch desktop images yet, especially if this delays the stable release.

I follow the problem but those solutions don't work: https://askubuntu.com/questions/826619/broken-network-settings-upon-boot

 

There is another interesting related problem. For imx6 Debian Stretch desktop works, Ubuntu Xenual crashes With mainline kernel.

[zador.blood.stained]

1 minute ago, Igor said:

There is another interesting related problem. For imx6 Debian Stretch desktop works, Ubuntu Xenual crashes With mainline kernel.

Then i.MX6 desktop should be taken off the current release list and built and uploaded manually when (and if) this issue is resolved. Since AFAIK you are the only person with i.MX6 hardware (and especially with several different devices) I'm not sure if anyone else can help here.

[Igor]

It's o.k. I already set imx desktop to Stretch https://github.com/armbian/build/blob/master/config/boards/cubox-i.conf#L11, others I need to revert back to Xenial for upcoming images update since I already changed to Stretch.

[TonyMac32]

Was certain I'd brought this up, but couldn't find it quickly (google search claims it's in the 7" touchscreen thread but it is not).  The legacy Tinkerboard image hangs for a period of time launching large apps in Debian Stretch.  The machine is not locked up, as the uart console is still responsive.  Nothing is showing up in logs.  The x-server simply becomes unresponsive, the "please wait" circle spins and it takes 3-4 minutes to "get over it" and move on.  Does not accept mouse or keyboard input through the GUI, behaves normally through the console.