jimg

Members
  • Content count

    18
  • Joined

  • Last visited

  1. Firefox (not Chromium this time) is now crashing on me when I attempt to launch it on an Orange Pi PC+. Seems to be related to a new security update I think I got (55.0.1+build2-0ubuntu0.16.04.2). Anyone else having this problem?
  2. Install to EMMC

    I can format it, but when I attempt to mount it by hand using the method in the create_armbian function of nand-sata-install , it fails: $ sudo mkdir -p /mnt/rootfs /mnt/bootfs $ sudo mount /dev/mmcblk1p1 /mnt/rootfs mount: wrong fs type, bad option, bad superblock on /dev/mmcblk1p1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. FWIW, I can confirm what Da Alchemist experienced--ext3 works, but not ext4.
  3. Install to EMMC

    I have an orange pi plus 2e with Debian 8 installed on the eMMC. I wanted to upgrade to Debian 9, so I downloaded the Debian Jessie server version of Armbian, put it on an SD card, changed /etc/apt/sources.list to point to Debian Stretch, uninstalled network-monitor and set the networking configuration by hand. Seems to be working OK, so now I'm trying to install it to the eMMC. But when I run 'sudo nand-sata-install', I get the following errors after it formats the disk to ext4: mount: wrong fs type, bad option, bad superblock on /dev/mmcblk1p1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. and the error dialog box reports: Partition too small. Needed: 2615 Mb Avaliable: Mb dmesg | tail returns: EXT4-fs (mmcblk1p1): couldn't mount RDWR because of unsupported optional features (400) Any idea what's happening? When I check mmcblk1 using fdisk, the disk looks to be partitioned properly (14.4 G 83 Linux).
  4. Could you explain what you did to get wicd to work? Do you have any special settings in /etc/network or /etc/wicd? I'm trying to connect to an access point over wireless using a WEP2 passphrase, but every time I attempt to connect I get "bad password". I can't connect to the internet over a wired connection, either, just to machines on the local LAN. (I'm guessing the latter issue is a DHCP setting problem.)
  5. That seems reasonable. Thanks for all your help. You've saved me lots of time.
  6. What are the incompatibilites between the legacy kernel and Stretch? Just curious... Will there every be a mainline kernel version developed for Stretch, or will Armbian no longer support Debian?
  7. I have been using Debian Jessie on an Orange Pi Plus 2e, but decided to upgrade to Stretch so I could install Chromium (which isn't in the Jessie repositories). I substituted 'stretch' for 'jessie' in /etc/apt/sources.list, then did: $ sudo apt-get update $ sudo apt-get dist-upgrade Everything went OK, until it hung while reconfiguring network manger. I restarted and re-ran sudo apt-get dist-upgrade. Everything else appeared to install OK except network-manager (which is shown as installed but half-configured) and network-manager gnome (which is shown as unpacked and not configured), If I try to fix network-manager using dpkg, this is what i get: $ sudo dpkg --configure network-manager Setting up network-manager (1.6.2-3) ... Job for NetworkManager.service failed because the control process exited with error code. See "systemctl status NetworkManager.service" and "journalctl -xe" for details. invoke-rc.d: initscript network-manager, action "restart" failed. ● NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Mon 2017-07-03 11:20:42 CDT; 50ms ago Docs: man:NetworkManager(8) Process: 4100 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=exited, status=226/NAMESPACE) Main PID: 4100 (code=exited, status=226/NAMESPACE) Jul 03 11:20:42 orangepiplus2e systemd[1]: NetworkManager.service: Unit entered failed state. Jul 03 11:20:42 orangepiplus2e systemd[1]: NetworkManager.service: Failed with result 'exit-code'. dpkg: error processing package network-manager (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: network-manager Here are the systemd error logs: $ systemctl status NetworkManager.service ● NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2017-07-03 11:35:20 CDT; 10s ago Docs: man:NetworkManager(8) Process: 4301 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=exited, status=226/NAMESPACE) Main PID: 4301 (code=exited, status=226/NAMESPACE) $ sudo journalctl -xe -- Subject: Unit NetworkManager.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit NetworkManager.service has failed. -- -- The result is failed. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Unit entered failed state. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Failed with result 'exit-code'. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Service hold-off time over, scheduling restart. Jul 03 11:35:20 orangepiplus2e systemd[1]: Stopped Network Manager. -- Subject: Unit NetworkManager.service has finished shutting down -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit NetworkManager.service has finished shutting down. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Start request repeated too quickly. Jul 03 11:35:20 orangepiplus2e systemd[1]: Failed to start Network Manager. -- Subject: Unit NetworkManager.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit NetworkManager.service has failed. -- -- The result is failed. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Unit entered failed state. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Failed with result 'exit-code'. Jul 03 11:35:58 orangepiplus2e sudo[4307]: jim : TTY=pts/1 ; PWD=/home/jim ; USER=root ; COMMAND=/bin/journalctl -xe Jul 03 11:35:58 orangepiplus2e sudo[4307]: pam_unix(sudo:session): session opened for user root by jim(uid=0)
  8. Now that Debian stable has moved from Jessie to Stretch, what would it take to move the Debian branch of Armbian to Stretch? Would it break anything if I just s/jessie/stretch/g in /etc/apt/sources.list and do sudo apt-get update && sudo apt-get dist-upgrade?
  9. The chgrp command is incorrect. It should be: $ sudo chgrp -HR gpio /sys/class/gpio/gpio10
  10. You are correct: it's not necessary to modify the FEX file to use the GPIO pins, and you should use the mainline formula to calculate pin numbers. I'll share what I learned attempting to solve this problem in case anyone else runs into it. As the error states, it's a permissions problem. Using "sudo echo" won't work because the redirection occurs before sudo is started, which ends up you trying to write to a file you don't have permissions to. To do a one-off manipulation of a GPIO pin, you have to start a separate shell as a superuser first, then use echo. For instance to turn pin A10 on: $ sudo sh # echo 10 > /sys/class/gpio/export # echo out > /sys/class/gpio/gpio10/direction # echo 1 > /sys/class/gpio/gpio10/value Or you can use tee to avoid creating a subshell: $ echo 10 | sudo tee /sys/class/gpio/export $ echo out | sudo tee /sys/class/gpio/gpio10/direction $ echo 1 | sudo tee /sys/class/gpio/gpio10/value A better, more permanent solution is to create a separate GPIO group, add yourself as a user to that group, and then give the GPIO group permissions to modify the GPIO pin directories: $ sudo groupadd gpio $ sudo usermod -aG gpio <your_username> $ su <your_username> $ sudo chgrp gpio /sys/class/gpio/export $ sudo chgrp gpio /sys/class/gpio/unexport $ sudo chmod 775 /sys/class/gpio/export $ sudo chmod 775 /sys/class/gpio/unexport You'll also have to modify the permissions on the directory of each GPIO pin you add. Again using pin A10 as an example: $ echo 10 > /sys/class/gpio/export $ chgrp -HR /sys/class/gpio/gpio10 $ chmod -R 775 /sys/class/gpio/gpio10 Then you can change that pin as necessary without being a superuser: $ echo out > /sys/class/gpio/gpio10/direction # set as output pin $ echo 1 > /sys/class/gpio/gpio10/value # set high $ echo 10 > /sys/class/gpio/gpio/unexport # reset the pin
  11. What is now the correct way to change the pin settings on kernel 3.4.113 if not modifying the FEX file? I didn't think it used Device Tree since it's below V 3.10. It still uses FEX files for other features (e.g., I got uart3 working on ttyS3 by simply editing the FEX file). FWIW, I had also tried using the mainline pin numbers to turn them on and off but still had the same problem. The example Accessing the GPIO pins through sysfs on sunxi-3.4 on the sunxi wiki uses a sequential numbering system defined by the FEX file to access the pins, not the mainline pin numbering system. That's why I tried using the method I did.
  12. I'm trying to use a few of the GPIO pins as output pins on an Orange Pi PC+ running Armbian 5.26 and legacy kernel 3.4.113-sun8i. When I look at the FEX file, it appears that the GPIO pins have all been disable d by default: [gpio_para] gpio_used = 0 gpio_num = 0 I don't recall them being disabled by default in previous versions of Armbian. I s this a recent change? Anyway, I edited the file and changed it to: [gpio_para] gpio_used = 1 gpio_num = 3 gpio_pin_1 = port:PA13<1><default><default><default> gpio_pin_2 = port:PA14<1><default><default><default> gpio_pin_3 = port:PD14<1><default><default><default> then did the following: $ fex2bin /tmp/custom.fex /boot/bin/custom.bin $ ln -sf /boot/bin/custom.bin /boot/script.bin <reboot> $ modprobe gpio-sunxi But I cannot seem to get the GPIO pins working: $ sudo echo 1 > /sys/class/gpio/export -bash: /sys/class/gpio/export: Permission denied Any advice on what I'm doing wrong?
  13. I have an Orange Pi Plus 2 that was running Armbian off of its onboard eMMC module, but I think I may have damaged it while working with the GPIO pins as it now will no longer boot from the module. The board will boot and run OK off of an SD card, but I'd like to copy the OS back to the eMMC module if possible. I've tried to rerun the script 'nand-sata-install', but I receive the error 'There are no targets. Please check your drives'. If I list the mmc devices I just get one, which I presume is the SD card: > ls -l /dev/ | grep mmcblk brw-rw---- 1 root disk 179, 0 Mar 20 16:51 mmcblk0 brw-rw---- 1 root disk 179, 1 Mar 20 16:51 mmcblk0p1 Does this mean the eMMC card is permanently damaged? Is there anything I could do to attempt to bring it back?
  14. I am having the same problem with UART2 on an Orange Pi+2 using the latest stable legacy version of Armbian (Armbian_5.20_Orangepiplus_Debian_jessie_3.4.112_desktop). It will receive, but it won't transmit. Convolu is correct; pin PA0 is misconfigured. In the fex file, PA0 has the following attributes: $ bin2fex /boot/script.bin | grep PA00 jtag_ms = port:PA00<3><default><default><default> uart_tx = port:PA00<2><1><default><default> gpio_pin_6 = port:PA00<1><default><default><0>But, according to sunxi-pio, it's an input pin: $ sudo sunxi-pio -m print | grep -E "^PA[0-4]<.*" PA0<0><0><0><0> PA1<2><1><1> PA2<2><1><1> PA3<2><1><1> PA4<2><1><1> Resetting the pin to match the settings of PA1 makes it work correctly as UART2_TX: $ sudo sunxi-pio -m PA0'<2><1><1>' $ sudo sunxi-pio -m print | grep -E "^PA[0-4]<.*" PA0<2><1><1> PA1<2><1><1> PA2<2><1><1> PA3<2><1><1> PA4<2><1><1> To expand on how Convolu got this to persist using systemd, here's what I did: 1. Create a service file in /etc/systemd/system using a text editor (must be run as root). Here's what my file looks like: $ cat /etc/systemd/system/pinA0_reconfigure.service [Unit] Description=Re-configure PinA0 as I/O for UART2_TX etc. [Service] Type=oneshot ExecStart=/usr/bin/sunxi-pio -m PA0'<2><1><1>' [Install] WantedBy=dev-ttyS2.device 2. Enable and start the service: $ systemctl enable pinA0_reconfigure.service created symlink from /etc/systemd/system/dev-ttyS2.device.wants/pinA0_reconfigure.service to /etc/systemd/system/pinA0_reconfigure.service. $ systemctl start pinA0_reconfigure.service