Jump to content

5.35/5.36 bug / questions collection

tkaiser

By tkaiser
in Advanced users - Development

 Share

Recommended Posts

tkaiser

tkaiser

Posted
Posted
  • 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?
Igor

Igor

Posted
Posted
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.

zador.blood.stained

zador.blood.stained

Posted
Posted
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.

Igor

Igor

Posted
Posted
1 minute ago, zador.blood.stained said:

to "known issues" in the changelog for this release.


Done and I put a link to "Known issue" to this thread. 

1
zador.blood.stained

zador.blood.stained

Posted
Posted
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.

1
tkaiser

tkaiser

Posted
  • Author
Posted
2 hours ago, zador.blood.stained said:

function in config/sources/$LINUXFAMILY.conf

 

How should this solve the problem I was talking about?

zador.blood.stained

zador.blood.stained

Posted
Posted
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".

1
tkaiser

tkaiser

Posted
  • Author
Posted
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?

zador.blood.stained

zador.blood.stained

Posted
Posted
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)

Latte

Latte

Posted
Posted

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

1
tkaiser

tkaiser

Posted
  • Author
Posted

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?

tkaiser

tkaiser

Posted
  • Author
Posted
28 minutes ago, tkaiser said:

Can anyone confirm?

 

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

ning

ning

Posted
Posted

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?

 

zador.blood.stained

zador.blood.stained

Posted
Posted
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.

Homoran

Homoran

Posted
Posted

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

ning

ning

Posted
Posted
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`

ning

ning

Posted
Posted
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

zador.blood.stained

zador.blood.stained

Posted
Posted
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.

tkaiser

tkaiser

Posted
  • Author
Posted

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...

1
Igor

Igor

Posted
Posted

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

tkaiser

tkaiser

Posted
  • Author
Posted
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.

Igor

Igor

Posted
Posted

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. 

Igor

Igor

Posted
Posted

v.5.36 Are we ready to rebuild repository on Sunday ... and update only BSPs and RPI monitor?

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