stroess

  • Posts

    6
  • Joined

  • Last visited

Recent Profile Visitors

287 profile views

stroess's Achievements

  1. Thx for yr response. Yes, I checked docs and FAQ, and googled - I still do not comprehend why for identical hardware boards the apt-get update/upgrade of an earlier Armbian release for the board leads to a different content of the /etc/armbian-release file, compared to a fresh installation of the Armbian provided for this board (in the above case the 5.90 stamp shown is from 7/2019 according to the Armbian changelog doc, the 20.02.1 from 2/2020). I am aware that an apt-get update/upgrade is a complex operation, but at least in respect to the resulting version identification of Armbian after the update/upgrade it should be unambiguous, compared to a fresh installation of the newest board Armbian image. Also, I do not comprehend why there is a difference between /etc/armbian-release and /etc/armbian-image-release, in the fresh installation case as well as in the update/upgrade case (see previous post). Plz note that both installations are running perfectly, so it is not an urgent problem - just a nagging confusion on my side regarding unique unambiguous version identifications. Regards - Robert
  2. Hi. Can someone please kindly shed a light on Armbian / Debian / Sunxi release information that is confusing me: I run Armbian Buster on two Cubietruck systems - one was freshly installed, the other upgraded from a previous installation. Both systems were apt-updated/apt-upgraded most recently with identical /etc/apt/sources.list, and subsequently rebooted. Both systems report identical "uname -a" (=Linux ... 5.4.30-sunxi #20.02.9 SMP) and /etc/debian_version (=10.3) information. The /boot folders have identical zImage resp. uInitrd links pointing to identical targets. Still the /etc/armbian-release resp. /etc/armbian-image-release infos differ: VERSION=20.02.1 vs. VERSION=5.90 resp. VERSION=20.02.0-rc0 vs. VERSION=5.75 Are both systems running the same Armbian as indicated by identical "uname -a" and /etc/debian_version, /boot files, and complete apt-get update/apt-get upgrade .... or are they still running somehow differing OSes as indicated by the different /etc/armbian-release files ? In latter case: what needs to be done to get them identical (aside from cloning the OS installation) if apt-get update/upgrade don't fix these assumed differences. Help kindly appreciated - Thx in advance - Regards - Robert (attached a side-by-side comparision of the all version infos) relinfo
  3. oh dear, yet another uptime string format I wasn't aware of ... sigh to fix the script for handling *any* variants of combinations of less / greater than days / hours / minutes of uptime, I've changed (and btw simplified) the script .. see above edited original post. PR was made now for both uptime/users/load and bonding devices IP ... I see the PR in my branch of my repository, and from my understanding of the documentation I assumed this PR would subsequently automatically be generated also in the main repo .. but it is not visible there, afaik :-O Thx for the feedback Cheers [and quoting Alan B. Shepard's prayer on my newbie's attempt with GitHub :-) ] - Rob
  4. You're welcome, Igor. My above post has been updated to provide a solution now for all 3 uptime format cases ("hh:mm," and "nn days, hh:mm," and "mm min,"). I tried opening a PR to the build engine you suggested .. but I'm very unsure on how to proceed .. so if you don't mind I'd rather shy away from messing up anything, and kindly ask you to add the two changes (uptime / bonding IP) provided above. Cheers - Rob
  5. Just a minor problem: uptime from procps-nf 3.3.15 (Armbian buster) - as used in 30-armbian-sysinfo to get uptime/logged-in users/load - generates different outputs if the uptime is either less or more than 1 day or less than 1 hour ("hh:mm" or "d days, hh:mm" or "nn min") - this gets the 30-armbian-sysinfo confused on gathering the logged-in user count resp. load. I suggest the below fix: ... # get uptime, logged in users and load # fix for uptime from procps-ng 3.3.15: reports uptime less then a day as "hh:mm," # but uptime larger than a day as "nn days, hh:mm," or "nn days, mm min", and less than 1 hour as "mm min," # which mixes up the assignments for user count and load in the original script # due to the various differing uptime value formats we'll cut out the components for uptime / user(s) / load # by bash string substitutions UPTIME=$(uptime) UPT1=${UPTIME#*'up '} #cut off begin of uptime string to string 'up' to remove time of day UPT2=${UPT1%'user'*} #cut off previous string to string 'user' to remove anything after and including string 'user' users=${UPT2//*','} #cut off previous string until last ',' if any to collect user(s) count users=${users//' '} #strip off blanks time=${UPT2%','*} #cut off last ',' and user count to collect any uptime time format time=${time//','} #get rid of any ',' if any load=${UPTIME#*'load average: '} # cut off everything before and including string 'load average: ' load=${load//','} #get rid of ',' separating the 1 - 5 - 15 load values #echo "debug UPT1=|$UPT1| UPT2=|$UPT2| users=|$users| time=|$time| load=|$load|" ... Also I suggest to allow bonding to be recognized for the IP address display by replacing the SHOW_IP_PATTERN with SHOW_IP_PATTERN="^bond*|^[ewr].*|^br.*|^lt.*|^umts.*" Regards - Rob (environment: Cubietruck / Armbian Buster 10.3 / Linux 5.4.20-sunxi) P.S. A big THX for the good work on Armbian to Igor and the other contributors !!!