Jump to content

g00d

Members
  • Posts

    35
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I understand now. https://forum.odroid.com/viewtopic.php?f=93&t=36213 thanks for clarification
  2. Hello everybody, is it possible in u-boot (boot.ini) to make a user input and let the user choose from A or B and according to the choice load a particular uInitrd? In case a non-valid answer is given a default answer should be used. Best of all would be if I could implement a time-out. When user does not make input answer B should be selected. I would know how to do this in bash but is that also possible in boot.ini somehow?
  3. Well, according to the mentioned links to check WOL support my board returns: ethtool eth0 and nmcli c show "Wired Connection 1" so shouldn't it be supported then? What else do I need to make this auto-poweroff auto-resume stuff work? any tools, scripts you can suggest to try? is there any alternative like using suspend/hibernate instead of shutdown? how could I save energy on the ODROID-HC2 while not used, any helpful hints?
  4. I've found the Debian Wiki about WOL but I am missing information on how auto-shutdown/auto-suspend etc. works on Armbian. Whick packages, configuration files are needed for setting up energy power save mode in Armbian Bullseye on ODROID-HC2 ? Is Debian Suspend Wiki to go for? I'd like my ODROID-HC2 to power-off somehow to save energy, especially during night periods where the NAS isn't used usually. My ODROIC-HC2 runs as a NAS with samba setup. Can anyone point me to the right direction, please? thank you.
  5. Hello everybody, I am not using OpenMediaVault but I am trying to implement some of its feautures into my existing system based on Armbian Bullseye, running on ODROID HC-2. Is there any tutorial or HowTo available that explains steb-by-step how to install and setup auto-shutdown feauture and WOL? I'd like my odroid hc-2 shut-down when not in use (especially over night) and let it auto-start again whenever I access it via \\myhost\share or \\192.168.0.1\someshare. If that's not possible then I can live with sending a WOL magic packet manually. Any known tutorial avaible for doing this on a ODROID-HC2 ?
  6. g00d

    overlays

    thanks for all the information provided. Honestly said I am not familiar in decompiling and reading such code. If anyone else can provide some more answers to my previous questions related to the ODROID-HC2 board in this matter, please let me know. Thanks in advance. As I am not using a special housing like cloudshell and unless there is no advantage, I will leave the settings cs2 to default off so the mentioned overlay are not loaded at system boot.
  7. g00d

    overlays

    Hi tparys, thanks for the link that was kinda helpful but I still have some questions. As I showed in my initial posting my boot.ini loads three overlay files when variable cs2enable is set to true. Those three overlay are setenv overlays "i2c0 i2c1 hktft-cs-ogst" A) how do I know what these overlay are good for and used for? The default boot.ini does NOT load them. They are loaded only if I set cs2enable=true, the comments in boot.ini says that this is only needed when using a CloudShell2 enclosure to enable TFT LCD and FAN control via i2c bus. Well, in my case I don't have a CloudShell2 because I am using simply a ODROID-HC2 (equivalent to odroidxu4 board). If understood correctly I can leave cs2enable to default setting "false" and thus don't need loading those overlay. Is this correct? the boot.ini of my ODROID-HC2 installation does not match any more lines with search pattern "overlay". Does that mean that none of the rest overlay files are important in my case? dtb-5.4.151-odroidxu4/overlays: insgesamt 40K -rw-r--r-- 1 root root 1,7K 8. Okt 21:52 ads7846.dtbo -rw-r--r-- 1 root root 1,3K 8. Okt 21:52 hktft32.dtbo -rw-r--r-- 1 root root 1,8K 8. Okt 21:52 hktft35.dtbo -rw-r--r-- 1 root root 1,5K 8. Okt 21:52 hktft-cs-ogst.dtbo -rw-r--r-- 1 root root 224 8. Okt 21:52 i2c0.dtbo -rw-r--r-- 1 root root 226 8. Okt 21:52 i2c1.dtbo -rw-r--r-- 1 root root 417 8. Okt 21:52 onewire.dtbo -rw-r--r-- 1 root root 691 8. Okt 21:52 spi0.dtbo -rw-r--r-- 1 root root 792 8. Okt 21:52 sx865x-i2c1.dtbo -rw-r--r-- 1 root root 227 8. Okt 21:52 uart0.dtbo - how do I know what the rest of the overlays are good for? I wasn't able to find any hint in the link you posted or on the comments. There is also no README.<soc-id>-overlays on my installation under /boot/dtb/overlay/ (32-bit SoCs) or /boot/dtb/allwinner/overlay/ (64-bit SoCs) and this link doesn't reveal any information about the overlays and what they are useful for for which boards, etc. Can anyone tell me please, which overlays are possibly interesting for the ODROID-HC2 ? thanks to all!
  8. g00d

    overlays

    Hello all, my boot partition contains following file structure: # ls -lh insgesamt 20M drwxr-xr-x 3 root root 4,0K 11. Nov 16:27 ./ drwxr-xr-x 3 root root 4,0K 16. Nov 09:24 ../ -rw-r--r-- 1 root root 38K 8. Okt 22:10 boot.bmp -rw-r--r-- 1 root root 14K 27. Okt 16:52 boot.ini lrwxrwxrwx 1 root root 21 8. Okt 22:10 dtb -> dtb-5.4.151-odroidxu4/ drwxr-xr-x 3 root root 4,0K 8. Okt 22:10 dtb-5.4.151-odroidxu4/ -rw-r--r-- 1 root root 0 8. Okt 22:10 .next lrwxrwxrwx 1 root root 25 27. Okt 16:58 uInitrd -> uInitrd-5.4.151-odroidxu4 -rw-r--r-- 1 root root 13M 27. Okt 16:58 uInitrd-5.4.151-odroidxu4 -rwxr-xr-x 1 root root 7,0M 8. Okt 21:52 vmlinuz-5.4.151-odroidxu4* lrwxrwxrwx 1 root root 25 8. Okt 22:10 zImage -> vmlinuz-5.4.151-odroidxu4* # ls -lh dtb-5.4.151-odroidxu4/* -rw-r--r-- 1 root root 41K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos3250-artik5-eval.dtb -rw-r--r-- 1 root root 52K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos3250-monk.dtb -rw-r--r-- 1 root root 57K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos3250-rinato.dtb -rw-r--r-- 1 root root 59K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4210-origen.dtb -rw-r--r-- 1 root root 56K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4210-smdkv310.dtb -rw-r--r-- 1 root root 61K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4210-trats.dtb -rw-r--r-- 1 root root 63K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4210-universal_c210.dtb -rw-r--r-- 1 root root 100K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-i9300.dtb -rw-r--r-- 1 root root 100K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-i9305.dtb -rw-r--r-- 1 root root 74K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-itop-elite.dtb -rw-r--r-- 1 root root 97K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-n710x.dtb -rw-r--r-- 1 root root 72K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-odroidu3.dtb -rw-r--r-- 1 root root 72K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-odroidx2.dtb -rw-r--r-- 1 root root 72K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-odroidx.dtb -rw-r--r-- 1 root root 71K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-origen.dtb -rw-r--r-- 1 root root 63K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-smdk4412.dtb -rw-r--r-- 1 root root 62K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-tiny4412.dtb -rw-r--r-- 1 root root 100K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos4412-trats2.dtb -rw-r--r-- 1 root root 62K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5250-arndale.dtb -rw-r--r-- 1 root root 58K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5250-smdk5250.dtb -rw-r--r-- 1 root root 63K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5250-snow.dtb -rw-r--r-- 1 root root 63K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5250-snow-rev5.dtb -rw-r--r-- 1 root root 60K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5250-spring.dtb -rw-r--r-- 1 root root 23K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5260-xyref5260.dtb -rw-r--r-- 1 root root 44K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5410-odroidxu.dtb -rw-r--r-- 1 root root 33K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5410-smdk5410.dtb -rw-r--r-- 1 root root 78K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5420-arndale-octa.dtb -rw-r--r-- 1 root root 86K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5420-peach-pit.dtb -rw-r--r-- 1 root root 72K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5420-smdk5420.dtb -rw-r--r-- 1 root root 81K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5422-odroidhc1.dtb -rw-r--r-- 1 root root 87K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5422-odroidxu3.dtb -rw-r--r-- 1 root root 87K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5422-odroidxu3-lite.dtb -rw-r--r-- 1 root root 86K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5422-odroidxu4.dtb -rw-r--r-- 1 root root 87K 8. Okt 21:52 dtb-5.4.151-odroidxu4/exynos5800-peach-pi.dtb dtb-5.4.151-odroidxu4/overlays: insgesamt 40K -rw-r--r-- 1 root root 1,7K 8. Okt 21:52 ads7846.dtbo -rw-r--r-- 1 root root 1,3K 8. Okt 21:52 hktft32.dtbo -rw-r--r-- 1 root root 1,8K 8. Okt 21:52 hktft35.dtbo -rw-r--r-- 1 root root 1,5K 8. Okt 21:52 hktft-cs-ogst.dtbo -rw-r--r-- 1 root root 224 8. Okt 21:52 i2c0.dtbo -rw-r--r-- 1 root root 226 8. Okt 21:52 i2c1.dtbo -rw-r--r-- 1 root root 417 8. Okt 21:52 onewire.dtbo -rw-r--r-- 1 root root 691 8. Okt 21:52 spi0.dtbo -rw-r--r-- 1 root root 792 8. Okt 21:52 sx865x-i2c1.dtbo -rw-r--r-- 1 root root 227 8. Okt 21:52 uart0.dtbo the boot.ini contains following part: if test "${cs2enable}" = "true"; then fdt resize 8192 setenv overlays "i2c0 i2c1 hktft-cs-ogst" for overlay in ${overlays}; do ext4load mmc 0:1 0x60000000 /boot/dtb/overlays/${overlay}.dtbo fdt apply 0x60000000 done fi can anyone explain to me in simple words what these overlays are good for? are they needed, what is their job? I tried commenting out the line here # ext4load mmc 0:1 0x60000000 /boot/dtb/overlays/${overlay}.dtbo and the system still booted normally without any noticeable difference during boot and operation. Can anyone shed some light onto, please? thanks
  9. Hi Werner, yes of course HIM. The kind of that script is absolutely inacceptable. No warning, no checks, nothing, he's just wiping! even with CTRL+C at script termination. But I wrote this topic to warn the armbian community and hopefully the developers behind it. This script was never downloaded and installed by myself into my Armbian OS. It is shipped with Armbian. That is why I wrote here so the devs can check and remove this irresponsible script from Armbian Bullseye image. The image I am using is Armbian_21.08.3_Odroidxu4_bullseye_current_5.4.151.img and I just checked the content. The mentioned bad script is located in /usr/bin/wireguard-manager @devs: please check and decide if you wanna keep or remove this dangerous script from your nice Armbian work.
  10. Dear all, on my ODROID-HC2 Armbian Bullseye installation there is a script /usr/bin/wireguard-manager and I'm curious what this is about at all. In my opinion only wireguard-tools is "ok" to setup a wireguard VPN configuration but no "wireguard" package or such a script which installs a bunch of stuff and weird things. Unfortunately I was new to wireguard and this was my 1st configuration and setup I did. I discovered the mentioned script and executed "wireguard-manager --help" which against my expectation started an installation of different stuff. I didn't cancel this because I was afraid in ending in half-baked misconfigured states. It did "apt update" and also installed some packages on my system and even apt-get install linux-headers-"$(uname -r)" -y which failed because the kernel on my ODROID-HC2 is linux-image-current-odroidxu4. It removed chrony, installed ntp, gawk, and various other packages and it also modified or added some systemd/sysv scripts (don't remember exactly). While progressing I realized that I never ever needed this script and now I'm afraid about the systemd modifications. Can anyone shed some light into this script, why it is there and how I can revert all modifications made by that script? It's really annoying that it didn't interprete the --help argument as expected and started the installation and configuration any helpful answer appreciated EDIT: WTF ?!?!?!?! according to the script arguments as shown on the GIT repo I wanted to try another argument, this time I used the neutral --list argument. It didn't list anything but it throwed an input. I didn't enter 1 or 2 but I pressed CTRL+C and returned to the bash prompt. And what the hell do I see ?? /etc/wireguard is WIPED !!! the folder is gone with all my configs and keys. It was there seconds ago and I did not execute any other commands meanwhile. History proves this and also "locate wireguard" which is still displaying /etc/wireguard in the cache db. This is ridigoulous, what the f*** is this script doing? This is broken and needs to get removed. I'm really really PIS*** !!!!! root@host:/# wireguard-manager --list Do you want the interface (server) or peer (client) to be installed? 1) Interface 2) Peer Interface Or Peer [1-2]: 1^C root@host:/# cd /etc/wireguard NOT FOUND !!! EDIT: this is reproducable. This sucks! And there is NO backup folder created under /var/backups with variable WIREGUARD_OLD_BACKUP or SYSTEM_BACKUP_PATH variable. Damn it, REMOVE THIS SCRIPT! this script is irresponsible and belongs removed from Armbian ! rm -rf /usr/bin/wireguard-manager
  11. Well, I made some progression and want to share it with the community: Related to question 1) still unresolved because I don't know if I am missing something or this could possibly be a bug? Related to question 2) the culprit lies inside the function storage_info() because I am not using simply /dev/sda1 but an encrypted drive. My disk *is* /dev/sda1 but it's LUKS encrypted and so my device for the system is /dev/mapper/rootfs or even more /dev/mapper/volumeGroup1-rootfs because I am also using LVM. The storage_info() function does not take this into account. I had to modify the function to this here: function storage_info() { # storage info RootInfo=$(df -h /) root_usage=$(awk '/\// {print $(NF-1)}' <<<${RootInfo} | sed 's/%//g') root_total=$(awk '/\// {print $(NF-4)}' <<<${RootInfo}) StorageInfo=$(df -h $STORAGE 2>/dev/null | grep $STORAGE) #if [[ -n "${StorageInfo}" && ${RootInfo} != *$STORAGE* ]]; then if [[ -n "${StorageInfo}" ]]; then storage_usage=$(awk '/\// {print $(NF-1)}' <<<${StorageInfo} | sed 's/%//g') storage_total=$(awk '/\// {print $(NF-4)}' <<<${StorageInfo}) if [[ -n "$(command -v smartctl)" ]]; then #DISK="${STORAGE::-1}" storage_temp+=$(smartctl -l scttempsts $DISK 2> /dev/null | grep -i 'Current Temperature:' | awk '{print $(NF-1)}') storage_pwroff_retract_count=$(smartctl -a $DISK | grep Power-Off_Retract | awk '{print $10}') fi fi } # storage_info in detail: it needs to comment out the originally line #if [[ -n "${StorageInfo}" && ${RootInfo} != *$STORAGE* ]]; then and change it to: if [[ -n "${StorageInfo}" ]]; then it needs to comment the following line here inside the if clause: #DISK="${STORAGE::-1}" and it needs a definition in the top of the script where we need to add a DISK variable. Simply said, we need to separate DISK and STORAGE in case of encrypted systems and/or LVM used. The top of the script 30-armbian-sysinfo looks like that in my case: DISK=/dev/sda1 STORAGE=/dev/mapper/volumeGroup1-rootfs that way the script works fine and outputs the correct values. Related to question 3) solved also according to question 2. I added the threshold 50 for the power-off retract count in the beginning for the script: [...] CPU_TEMP_OFFSET=0 HDD_TEMP_LIMIT=60 PWROFF_WARN=25 [...] The variable and display command should look like that: disk_pwroff_retract_count=$(smartctl -a $DISK | grep Power-Off_Retract | awk '{print $10}') [...] # display info display "HDD PWRoff Retract Count" "$disk_pwroff_retract_count" $PWROFF_WARN "0" "times" "" ; a=$((a+$?)) [...]
  12. Hello community, when I SSH into my ODROID-HC2 I get the nice coloured MOTD which I really like. Question 1) I found the configuration file /etc/default/armbian-motd and the directory /etc/update-motd.d and after reading the bash code I lack in understanding why some information lines are suppressed in the MOTD banner when the scripts get executed. For example: I would expect to see some net traffic stats because /etc/default/armbian-motd uses the default setting PRIMARY_DIRECTION="rx" and the package "vnstat" is installed and "vnstat -i eth0" return correct output. I also tried changing PRIMARY_DIRECTION line to ="both" but I don't get any net status displayed in that MOTD banner. Why? EDIT: I found the culprit which lies in /etc/update-motd.d/30-armbian-sysinfo script. My PRIMARY_INTERFACE is eth0 and as such also defined in /etc/default/armbian-motd. But that line here: # Check whether PRIMARY_INTERFACE exist in /var/lib/vnstat/ PRIMARY_INTERFACE=$(comm -12 <(ls -1 /var/lib/vnstat/ 2> /dev/null) <(echo "$PRIMARY_INTERFACE" | sed 's/+/\n/g') | sed -n -e 'H;${x;s/\n/+/g;s/^+//;p;}') sets that variable to "blank" because the command shown above will fail. The content of /var/lib/vnstat in my case is only one single file called "vnstat.db". When I comment out that line, I get the expected output of RX and TX when running the 30-armbian-sysinfo script. Is anything known about this and can provide more information? Question 2) I don't get various stuff displayed, for example the disk temperature. It's not displayed when running the 30-armbian-sysinfo script although the command provided in the script for the variable "storage_temp" inside the function storage_info() works fine when executed at the bash prompt. Why does the command display "storage temp" "$storage_temp" $HDD_TEMP_LIMIT "0" "°C" "" ; a=$((a+$?)) not output the storage temperature ? Question 3) I also wanna display the last and current value of smartmontool for my SATA disk for ID#192 which corresponds to "Power-Off_Retract_Count". The command therefore is smartctl -a /dev/sda | grep Power-Off_Retract | awk '{ print $10 }' but where do I add this? I think it's not advised to modify /etc/update-motd.d/30-armbian-sysinfo file because on the next upgrade it will get overwritten, is it? My idea was modifying that file /etc/update-motd.d/30-armbian-sysinfo by adding a new line after line:162 in the function storage_info which stores the current desired value into the variable name storage_poff_retract : function storage_info() { # storage info RootInfo=$(df -h /) root_usage=$(awk '/\// {print $(NF-1)}' <<<${RootInfo} | sed 's/%//g') root_total=$(awk '/\// {print $(NF-4)}' <<<${RootInfo}) StorageInfo=$(df -h $STORAGE 2>/dev/null | grep $STORAGE) if [[ -n "${StorageInfo}" && ${RootInfo} != *$STORAGE* ]]; then storage_usage=$(awk '/\// {print $(NF-1)}' <<<${StorageInfo} | sed 's/%//g') storage_total=$(awk '/\// {print $(NF-4)}' <<<${StorageInfo}) if [[ -n "$(command -v smartctl)" ]]; then DISK="${STORAGE::-1}" storage_temp+=$(smartctl -l scttempsts $DISK 2> /dev/null | grep -i 'Current Temperature:' | awk '{print $(NF-1)}') storage_poff_retract=$(smartctl -a $STORAGE | grep Power-Off_Retract | awk '{print $10}') fi fi } # storage_info and the also after line 234 adding a new line to display this value: display "storage temp" "$storage_temp" $HDD_TEMP_LIMIT "0" "°C" "" ; a=$((a+$?)) display "storage Power-Off Retract Count" "$storage_poff_retract" "" ; a=$((a+$?)) though I am not sure if that would be correct because it doesn't work as expected and not displayed, same issue as in question 2. What do you think? Please point me to the right direction. Thanks!
  13. @Igor: I have one more question, maybe you can answer this, too? Is it possible to have u-boot look for 'foo.bar' instead of 'boot.ini' ? Is there any HowTo how this could be accomplished ?
  14. Me again. I figured out what the problem was and I was able to solve this like that: the original /boot structure contains three symbolic links, in my case on the ODROID-HC2 (which is equal to odroidxu4): dtb -> dtb-5.4.151-odroidxu4 uInitrd -> uInitrd-5.4.151-odroidxu4 zImage -> vmlinuz-5.4.151-odroidxu4 The default boot.ini is seeking for that link names but on the fat system it's not possible to have symbolic links. I just renamed (or one can simply copy) the existing three files like that: dtb-5.4.151-odroidxu4 ---to---> dtb uInitrd-5.4.151-odroidxu4 ---to---> uInitrd vmlinuz-5.4.151-odroidxu4 ---to---> zImage I also found out that /boot folder is NOT being red by boot process, it looks at the root folder for those files. So I "mv /boot/* /" moved the complete content of the /boot folder into the root. That way the boot process works like a charm. Thank you Igor for assistance. Have a nice weekend
  15. Hi Igor, thanks for the information provided. I have done several tests by starting with a functional uSD card. The bootloader is on the uSD card but I have problems with the first partition. I tried several partition types and file system combinations. When the first partition is formatted as ext4 or ext2 and containing the /boot folder the boot process finishes successfully. However when I format this partition with 'mkfs.vfat' or 'mkfs.fat' or 'mkfs.fat -F 16' the boot process will fail. According to the boot log it seems that U-Boot is expecting a ext* file system. I check boot.ini and to be sure I not only copied /boot folder to the partition 1 but also all the files additionally to the root of that partition. That way u-boot can look for the necessary files in / or in /boot but it didn't help. What am I missing here, how can I make the boot work successful by using vfat or fat16 ? thanks a bunch Did I miss anything or what else do I need to configure so
×
×
  • Create New...