5.35/5.36 bug / questions collection
4 4

61 posts in this topic

Recommended Posts

  • A while ago we added some logic to set LINUXFAMILY=sunxi in /etc/armbian-release and this breaks completely the IRQ affinity settings in /etc/init.d/armhwinfo (prepare_board function). Sunxi boards upgrading to 5.35 get slower with some use cases unless a fix in 5.36 is provided (though I've no idea how the fix should look like)
  • It seems board support packages on apt.armbian.com have been built a few days ago not containing latest fixes. Is this possible?

Share this post


Link to post
Share on other sites
48 minutes ago, tkaiser said:

It seems board support packages on apt.armbian.com have been built a few days ago not containing latest fixes. Is this possible?

 

Possible. They were made 22.11.

Share this post


Link to post
Share on other sites
Just now, Igor said:

yes.

Then IMO we should put this (and the workaround for images that have /boot/armbianEnv.txt) to "known issues" in the changelog for this release.

 

Just now, Igor said:

perhaps sun4i too?

No, CMA was enabled only on sun7i.

Share this post


Link to post
Share on other sites
On 25.11.2017 at 7:30 PM, tkaiser said:

though I've no idea how the fix should look like

As an example - as I proposed some time ago: platform specific performance tweaks go to a function in config/sources/$LINUXFAMILY.conf and are maintained there, this function is "extracted" into a separate file that is included by /etc/init.d/armhwinfo

Same with platform specific firstrun tweaks where they are required.

 

6 minutes ago, Igor said:

Moving(or copying) read configuration up?

this block (IMAGE_TYPE related) can be moved to line 260 and this should fix the problem.

pfeerick likes this

Share this post


Link to post
Share on other sites
10 minutes ago, tkaiser said:

How should this solve the problem I was talking about?

It won't solve the problem right away but it would be harder to miss such changes in a small file rather than in a 80+ lines long function in a 450 lines long file.

Regarding solving the problem - IMO we should push a bugfix update in a week, replacing at least board support packages - this will include armhwinfo fixes and will properly mark images as "stable" rather than "user-built".

pfeerick likes this

Share this post


Link to post
Share on other sites
59 minutes ago, zador.blood.stained said:

It won't solve the problem right away but it would be harder to miss such changes in a small file rather than in a 80+ lines long function in a 450 lines long file.

Hmm... I don't understand since this commit started to redefine LINUXFAMILY based on $something and when I got rid of the hardware detection stuff in armhwinfo relying on LINUXFAMILY being set to the value in board config files the problem started (and I only noticed recently testing with LanTest since performance was worse than months before). And I still don't have the slightest idea how a fix should look like since the root cause is redefining LINUXFAMILY based on $something and not code somewhere else trying to rely on LINUXFAMILY.

 

How should this be fixed? Introducing REALLINUXFAMILY?

Share this post


Link to post
Share on other sites
23 minutes ago, tkaiser said:

this commit started to redefine LINUXFAMILY based on $something

No, it only moved this logic from main.sh (and from configuration.sh previously) to config/sources/sunxi-common.inc

 

27 minutes ago, tkaiser said:

How should this be fixed? Introducing REALLINUXFAMILY?

Either this or something like parsing /proc/device-tree/compatible (which I would prefer assuming I remember correctly that "grep" can deal with null-separated string arrays)

Share this post


Link to post
Share on other sites

With the today's update (v5.35) there are ongoing messages (every minute) written to the journald log:

 

Nov 26 22:56:01 cubietruck cron[520]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates)

 

in fact the file seems to have the wrong permission:

 

root@cubietruck:/etc/cron.d# ls -l
total 16
-rw-rw-r-- 1 root root   83 Nov 21 12:14 armbian-updates
-rw-r--r-- 1 root root  484 Nov  4  2016 certbot
-rw-r--r-- 1 root root  661 Sep  8  2015 php5
-rw-r--r-- 1 root root 2320 May  7  2017 sendmail

 

after chmod 644 the messaging stops:

Nov 26 22:57:01 cubietruck cron[520]: (*system*armbian-updates) RELOAD (/etc/cron.d/armbian-updates)

 

It's easy to fix, so this is just for information...

 

 

Thanks,

Marc

Igor likes this

Share this post


Link to post
Share on other sites

Just for the record: /etc/init.d/armhwinfo on my 5.35 test installations is neither executed on startup nor shutdown and it needs a manual

systemctl enable armhwinfo

to get it working. Can anyone confirm?

Share this post


Link to post
Share on other sites

I can remember it is rootfs package updated. and push some new config file to /etc

1, new /etc/network/interfaces

          -- break NetworkManager

          -- remove lines for eth0

 

2, new lightdm config file: /etc/lightdm/lightdm.conf.d/armbian.conf

          -- break lightdm autologin defined in /etc/lightdm/lightdm.conf

          -- remove new config file

 

3, ssh banner always says: new update available:

 [ 0 security updates available, 16 updates total: apt upgrade ]

          -- No update actually.

          -- not fixed. and how to fix?

 

Share this post


Link to post
Share on other sites
4 hours ago, ning said:

I can remember it is rootfs package updated. and push some new config file to /etc

What was the old rootfs package version? Are you sure that /etc/network/interfaces was changed by the upgrade?

 

4 hours ago, tkaiser said:

Hmm... does only apply to two updated Banana installations. I'll look more into...

There was this problem due to missing some checks in the postrm BSP script, so this behavior will depend on the previous package version.

Share this post


Link to post
Share on other sites

Hi Igor,

 

The command

update-rc.d firstrun defaults

seems not to work anymore 

I have tried several times on a tinkerboard image, but it doesn't start at reboot.

 

there is the following output after entering the command:

root@tinkerboard:~# update-rc.d firstrun defaults
insserv: warning: current start runlevel(s) (empty) of script `firstrun' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `firstrun' overrides LSB defaults (0 1 6).

 

 

btw, did you think about to add this options (resize fs; change passwd etc.) to the armbian-config tool?

 

Greetz

Rainer

Share this post


Link to post
Share on other sites
5 hours ago, zador.blood.stained said:

What was the old rootfs package version? Are you sure that /etc/network/interfaces was changed by the upgrade?

 

There was this problem due to missing some checks in the postrm BSP script, so this behavior will depend on the previous package version.

I update system frequently, so old version should be 5.34: current package full name is linux-jessie-root-orangepipc_5.35_armhf.deb

 

after check package, it copies /etc/network/interfaces.default to /etc/network/interfaces by postinst scrpit.

 

`[ ! -f "/etc/network/interfaces" ] && cp /etc/network/interfaces.default /etc/network/interfaces`

Share this post


Link to post
Share on other sites
9 hours ago, ning said:

3, ssh banner always says: new update available:

 [ 0 security updates available, 16 updates total: apt upgrade ]

          -- No update actually.

          -- not fixed. and how to fix?

 

fixed by remove /var/cache/apt/updates.number

Share this post


Link to post
Share on other sites
7 hours ago, ning said:

after check package, it copies /etc/network/interfaces.default to /etc/network/interfaces by postinst scrpit.

 

`[ ! -f "/etc/network/interfaces" ] && cp /etc/network/interfaces.default /etc/network/interfaces`

Only if this file didn't exist before the installation/upgrade. Did you delete it (and i.e. not leave an empty file instead)? This upgrade scenario wasn't considered.

Share this post


Link to post
Share on other sites

Tried a new image on a Pinebook and am slightly shocked. A huge penguin is starting at me. When/where was the wallpaper switch from armbian06-1430-very-dark to armbian03-Dre0x-Minum discussed? I want to understand the reasons...

pfeerick likes this

Share this post


Link to post
Share on other sites
16 minutes ago, Igor said:

Desktop wallpaper Screen #1 and Screen #2 was swapped - Why not?

 

Sorry, I'm missing words. But this also explains so much and why it's useless to waste even one more second on everything UI related with Armbian.

Share this post


Link to post
Share on other sites

You monitor changelog on a daily base. How come that you miss this change, written in release docs for some time ... and is cosmetic anyway? Icon theme was also changed since the old one didn't want to install on Debian Stretch under chroot. Couldn't find why / solution. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

4 4

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.