lanefu

  • Posts

    1177
  • Joined

  • Last visited

Reputation Activity

  1. Like
    lanefu reacted to Skibbi in Small glitch in motd script   
    Hello,
    Recently I installed docker on my armbian and motd got broken. Previously it was printing correctly information about traffic:
    RX today: 20,72 GiB But after installing docker and playing with some images motd is displaying following error:
    RX today: Error: Not all requested interfaces found in database or given interfaces aren't unique. The problem is that docker adds new network interfaces that are not initialized in vnstat. I've solved my issue by adding the new docker interfaces in vnstat:
    vnstat --add -i docker0 vnstat --add -i veth160e0f9 Perhaps /etc/update-motd.d/30-armbian-sysinfo script should somehow detect new interfaces and add them automatically to vnstat or maybe variable in /etc/default/armbian-motd should not include virtual interfaces?
    PRIMARY_INTERFACE="$(ls -1 /sys/class/net/ | grep -v lo | sed -n -e 'H;${x;s/\n/+/g;s/^+//;p;}')"  
  2. Like
    lanefu reacted to Groove On in Odroid N2+, 3.5mm analog audio, alsamixer settings   
    If anyone needs to get the 3.5mm audio jack working on the N2+, here's one method.
     
    1. Edit or create /etc/asound.conf with these lines. Copied directly from the Hard Kernel Ubuntu setup.
     
    pcm.!default{     type hw     card 0     device 1 } ctl.!default{     type hw     card 0 }  
    2. Run this script to turn on the 3.5mm audio in alsamixer. The settings are listed in the same order as in alsamixer.
    #!/bin/bash  # 3.5MM JACK, set to max gain  amixer sset 'ACODEC' '255' # 3.5MM JACK - set in/out channels (src/sink) amixer sset 'FRDDR_B SINK 1 SEL' 'OUT 2' || true amixer sset 'FRDDR_B SRC 1 EN' 'on' || true # 3.5MM JACK amixer sset 'TOACODEC SRC' 'I2S C' || true amixer sset 'TOACODEC OUT EN' 'on' || true amixer sset 'TOACODEC Lane Select' '0' || true # SAVE NEW SETTINGS alsactl store  
  3. Like
    lanefu reacted to thc013 in 20.08 Orange Pi 4 - Kernel Enabled Bootsplash   
    it is not a bootsplash problem
     
    at boot the kernel searches for device and activates them and if a device takes time to get seen by the kernel the kernel get a amount of time to wait
    so when a device for example my usb3 got called before the bootsplash there is no bootsplash because kernel is waiting for the usb before he wants to put something on screen.
     
    you can see that effect if you boot through a console then you see the kernel spit out messages sometimes fast sometimes slower
    and it happens even more when you reboot but that is more less nowdays because the drivers are getting better
     
  4. Like
    lanefu reacted to going in creating packages in the armbian build system   
    I'm sorry. These are rhetorical questions.
    I can't get used to articulating thoughts in the style of English grammar so that the automatic translation looks correct.
    In fact, I am an experienced user and will find any information.
    But if we give the user the ability to search, update, or reinstall by key tags, it will be very good.
     
    sudo apt search armbin
    This command will display the full list of packages provided by armbian.
    sudo apt search armbin-edge
    This command will only show packages for $BRANCH
    It is the word combination that is important here armbian-$BRANCH
    sudo apt reinstall armbian-current
    This command will actually do a package update for the $BRANCH
     
    Here we not only take care of the user, but also improve the armbian.
     
    @Igor Yes, but only for those packages that contain programs, libraries that have their own version.
    This is necessary to correctly register the mutual dependencies.
    And this is especially true for the kernel and libraries that use the functionality of this particular kernel.
    The final version can be formed by concatenating the original version and the armbian version.
  5. Like
    lanefu reacted to Igor in How to create a new board for development?   
    Examples:

    - new board to existing family
    - new board and new family
  6. Like
    lanefu reacted to indianajones in Fast interrupt handling in AllWinner H3 using Linux Kernel Module   
    Good news! I was able to follow the devmem2 instructions in this forum article posted by @Ohms, and get all 26 pulses (by modifying the debounce timer).  Result!
  7. Like
    lanefu reacted to manuti in Inconsistent mount point on Banana Pi Pro over SATA   
    After mounting and unmounting several times both external units it seems to start working. Now the mount point at /sda is consistent across all the commands. The outpus you asked, @lanefu, is:
    ls -l /dev/disk/by-uuid total 0 lrwxrwxrwx 1 root root 15 may 11 22:57 d4e4d15d-d587-4f5d-83d7-4cbb1700e7c5 -> ../../mmcblk0p1 lrwxrwxrwx 1 root root 9 may 11 22:57 dcb5a19c-6bd2-4c5a-8fc4-9ed4adec7074 -> ../../sdb lrwxrwxrwx 1 root root 9 may 11 22:57 e6201983-bfd8-4eae-bf54-90575f09835f -> ../../sda  
    I also added a new screenshot. Thanks for the help. And I'll keep an eye on this if it happens again.

  8. Like
    lanefu reacted to Igor in creating packages in the armbian build system   
    ... has been changed to https://github.com/armbian/build/blob/master/lib/main.sh#L395-L396 so this package is only board specific now. Similar variant will come for desktop.

    Anyway, since release days are over, this can be moved in - if ready. FYI, there is another larger chunk of additions by @rpardini which needed review, understanding and integration. Not directly related, but imo it's wise not to merge both at once. @lanefu
  9. Like
    lanefu got a reaction from manuti in Inconsistent mount point on Banana Pi Pro over SATA   
    okay sorry I didn’t understand the issue exactly.
     
    so I believe this is a technicality of using lsblk.   A btrfs subvolume isn’t going to trace back to a block device.   Would be interesting to look at the output of 
     
    ls -l /dev/disk/by-uuid
     
  10. Like
    lanefu got a reaction from Werner in A SBC for computing - your thoughts   
    IMHO I'd omit HDMI or any sort of output other than console.    If the eMMC is a detachable module, then yeah eliminating SDCard is a good idea.
  11. Like
    lanefu reacted to SteeMan in A SBC for computing - your thoughts   
    When designing a good sbc for general compute/server tasks I think you need a set of features that enable both a 'desktop' as well as 'server rack' deployment.  The reason for this is the evaluation process someone will likely undertake in order to buy into the boards features. No one is going to buy 32 boards for a 'server rack' deployment as the first purchase.  Instead they are likely to purchase one or a few to evaluate first.  That evaluation is not going to happen in a rack mount, but instead will happen on a desktop.  Once someone is comfortable that the base board works for their basic needs (i.e. the software and general hardware works), then they will explore the 'server rack' deployment options as they plan to scale a use of the board.
    In my opinion therefore you need to make sure you have the features necessary to have a good evaluation experience on the desktop for the board ultimately to be successfully purchased in larger quantities for server work.  One example of this is an hdmi port.  While an hdmi port is completely useless in a server deployment, it can be quite useful during board evaluation on a desktop.  Another example is cooling as mentioned in the above posts.  I think you need to have good thermal design for both deployment scenarios (both as a desktop board and in a server rack mount), which might require different heat dissipation strategies for the different environments. Finally POE while likely unnecessary for a desktop evaluation is critical for a server deployment.
     
    My ideal feature list would be:
    1gbit POE ethernet port
    4GB ram
    32GB emmc (or more optional)
    good external storage options (m.2 or other)
    hdmi port
    2 or more usb ports (at least one being usb3)
    power port for non POE usage
    optional case for desktop use with good thermals
    optional rack mount with good thermals
     
    The two things I think it shouldn't have:
    - no wifi/bluetooth
    The reason I say these are not desired is that good wireless (good antenna's, good software support) is difficult to design into a board, it isn't needed in the server rack case and can be accomplished better with a usb addon for the desktop case without incurring the added cost to the base board.
    - no SD card
    The reason I wouldn't include an sd card slot is if emmc is standard, that will be the preferred deployment storage media.  You only need another option to install/update the internal emmc and usb should be sufficient for that.  The sd support then just becomes an added cost with no real long term need.  It does require that booting from usb be well supported by the firmware.
     
    Such a board would span a lot of use cases from general purpose single desktop use case to hundreds of boards deployed in dense rack configurations.
     
    My personal experience is that I try things out first by evaluating one of something, then scale up to a few, and ultimately more as each step of the evaluation process shows the product is capable of the next deployment step.
     
    Finally I'll mention price.  In my opinion you likely need the above described board at a price point no more than a RaspPi.  Given the large ecosystem and mind share built around that platform, and it is already capable of doing the above (although not well in many respects), you can't have something like this be at a 'high end' premium price point and expect it to be successful.  Price will to an extent drive the evaluation process.  If the price is considered too high, then people won't even start the evaluating, they will just stick with what the everyone else uses.
     
  12. Like
    lanefu got a reaction from PetrozPL in Rock Pi4 pwm control - no overlay?   
    Thanks @PetrozPL
    Added
    https://armbian.atlassian.net/browse/AR-735
  13. Like
    lanefu got a reaction from SteeMan in A SBC for computing - your thoughts   
    I want a stripped down board that has real 802.3af POE
  14. Like
    lanefu got a reaction from gounthar in A SBC for computing - your thoughts   
    I want a stripped down board that has real 802.3af POE
  15. Like
    lanefu reacted to gounthar in A SBC for computing - your thoughts   
    The thing is I want to be able to incorporate my SBCs in some 19" rack (1 U preferably), in desk grommet, or any other type of enclosure, so I don't want a well designed enclosure, as it won't help me.
  16. Like
    lanefu reacted to arox in A SBC for computing - your thoughts   
    Manufacturers will always add all hardware features that does not cost a lot : i.e. crappy cheap wifi and so on, because they do not bother to provide good drivers.
     
    In the other hand, RAM is always priced a lot and thermal design bad. If I want a SBC for specific use case like computing (and not a X86 server), I want it to be passively cooled and energy efficient. Storage is also a choice : either emmc, either a good bus design for drives.
     
    I simply cannot find a SBC for a use case because they are all designed for "general purpose" like a RPI or expensive with no guarantee of software support.
     
  17. Like
    lanefu reacted to rpardini in Help With Understanding Firstrun and Resetting Armbian Images   
    Hey @Jeremiah Cornelius 
    I've been working on something similar it seems, thanks to @lanefu for making the connection.
    Although the path I took was directly modifying the Armbian build scripts, instead of modifying a live image and then re-packing it.
     
    My fork of Armbian is quite complex, but I'm slowly splitting and reorganising things (and sometimes writing a metaprogramming Bash framework in the process ) 
    A few points that may be of interest to you:
     
    - Onboarding replaced by cloud-init, instead of any interactive onboarding, I configure cloud-init to read some YAML files from /boot.
      /boot/network-config can configure all aspects of networking (including wifi), /boot/meta-data is just that, and /boot/user-data can do almost anything, create users, passwords, import SSH keys, install packages, run scripts, resize rootfs, create SSH host keys, etc.
      cloud-init is of course focused on cloud images, but actually can be used on any environment, if you can stomach its YAML and hammer on its config.
      With cloud-init comes netplan.io (in place of NetworkManager) and some other stuff that may not be appropriate for your use-case so take with a grain of salt.
      Also my implementation is not bullet-proof yet, but it aims to work just like the Ubuntu RaspberryPi 4 "Server" image (also has cloud-init out of the box).
      Most of it is done in https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/cloud-init/cloud-init.sh (including the .not_logged_in_yet thing)
      Some other related stuff in https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/more_like_ubuntu_cloud.sh (which disables a bunch of stuff in the BSP,  during BSP-generation, so that reinstalls/upgrades of the bsp package do not ruin everything).
     
    - A trick I call rootfs-in-rootfs, during the image build process, I capture an e2image ext4 dump of the produced ext4 rootfs and then include it in the rootfs.  A bit like having a directory full of files, creating a .zip of it, then including that .zip file inside itself  but without the compression.
      Then boot the SD card (which includes the rootfs dump inside) and run "e2image -racp /root/rootfs.ext4.e2img /dev/sda2" for example.
      The nice thing is that e2image (part of e2fsprogs) can do a "smart" copy (-c), knowing that reading is cheaper than writing, it can read both the source and destination and only write the changed blocks to the target. This allows for a very, very fast version of "nand_sata_install",  especially on the 2nd+ "flash".
      More speed comes from reading/writing some hundred-thousand whole blocks instead of possibly millions of files that rsync would need to inspect individually.
      The relevant code fragment is https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/rootfs_e2img_inside_rootfs.sh
     
    Hopefully these will be of some help,
    Ricardo
     
     
  18. Like
    lanefu reacted to Heisath in Armbian v21.05 (Jerboa) Release Thread   
    Hi,
     
    so I merged master into release candidate branch.  Can you please check the Jira issues that are still "In Progress", or can I assume they are all not done? Or are some expected to be closed in May?
     
    https://armbian.atlassian.net/secure/RapidBoard.jspa?rapidView=2&projectKey=AR
  19. Like
    lanefu reacted to jstefanop in [Invalid] - OrangePi 4 UART on Pins 8, 10?   
    After wasting way to much time on this finally figured it out...in case anyone NEEDs UART on Pin 8,10 (UART2B) this is how you do it
     
    Go to amrbian config and edit .dts file
     
    disable i2c3 port (shares same pins as UART2B) ...change status to "disabled" in i2c@ff130000
    hijack uart2 address to point to UART2B pins instead of UART2C (the debug pins)....change phandle-0 in serial@ff1a0000 to 0x143
     
    now this is all you technically need to do, but this is tied to ttyS2 which is also the serial console output which is configured i believe at the kernel level (if anyone know how to disable let me know), so we need to swap ttyS2 to another interface to voice this
     
    so i just changed serial@ff1a0000 to point to ttyS1 by doing below
    swap serial1 ->serial2
    swap uart1 -> uart2
     
    If anyone has an elegant way to do all of the above with a nice dts overlay lmk, have no idea how overlay syntax works. 
     
    BTW also tried directly hijacking serial1 and serial 3 which are disabled (by changing phandle-0), but it only works in serial@ff1a0000...i guess all UART2 ports (UART2a,b,c) are tied to this address. 
  20. Like
    lanefu reacted to tparys in Help With Understanding Firstrun and Resetting Armbian Images   
    Reason I do that is that I've used this technique to backup (or obliterate) full OS images. If I rsync from an image that doesn't have that new directory, it'll wipe out the mount.
     
    If I have the mount in a tmpfs at a known location, that shouldn't happen.
  21. Like
    lanefu reacted to Jeremiah Cornelius in Help With Understanding Firstrun and Resetting Armbian Images   
    Budgie is on my list - as I get kinks worked out with clean, vanilla Armbian. I am doing hybrid arm64 kernels and armhf userspace because of audio-plugins. This worked well for me in Pinebook Pro, etc.

    I'd do more with pure arm64, if I can solve some gaps with Carla, and when there's a 64-bit Linux Widevine. That's when Google decides they need a 64-bit Chromebook, I guess.
     
    — Jeremiah
  22. Like
    lanefu reacted to Jeremiah Cornelius in Help With Understanding Firstrun and Resetting Armbian Images   
    This is it!
    Touching /root/.not_logged_in_yet gets the desired, correctly reset behavior for the armbian-firstrun-config systemd unit. I knew it was some small, critical configuration I'd been missing.
    I now have what's needed for a community, unsupported Armbian Khadas VIM3 image that's functionally equivalent to Odroid N2+, and have plans for similar with 32-bit apt/userspace, which enables access to an armhf ecosystem of commercial audio software, and snap images.
     
    This also means that the VIM3 Twister OS image that I have some good interest in from users, can be updated to use this firstrun logic - with an addition that will hardlink the new user to the "pi" account on which Twister OS scripts and configurations depend.
     
    In the background are plans for ready-to-run Armbian VIM images with Budgie desktop and Elementary OS, pre-built. Being unsupported, some of these may advance from Focal to Groovy or Hirsute.
     
    Thanks!
  23. Like
    lanefu reacted to tparys in Help With Understanding Firstrun and Resetting Armbian Images   
    Make your changes to the image before you call rsync? /dev/shm/original is mounted rw unless you tell it otherwise.
     
     
    You monster
  24. Like
    lanefu reacted to Jeremiah Cornelius in Help With Understanding Firstrun and Resetting Armbian Images   
    Really thanks for this. It gives me a lot more to go on.
    I'll do more work in the next day or so, and be back with some updates - HOPEFULLY with some guidance to offer others, if successful!
     
    The ""${SDCARD}"/root/.not_logged_in_yet" is a GREAT hint!
    It's the opposite of touching a flag in the file system, so of course finding it in a configured system is impossible! I'd have taken a long time, before I got to it in the script sources.
     
    — Jeremiah
  25. Like
    lanefu got a reaction from kentAVR in Help With Understanding Firstrun and Resetting Armbian Images   
    Doing this should probably trigger it.  https://github.com/armbian/build/blob/master/lib/distributions.sh#L157

    Also take a look at 

    https://github.com/armbian/build/blob/master/lib/distributions.sh#L372-L379

     

    Might be related to https://github.com/armbian/build/blob/master/packages/bsp/common/lib/systemd/system/armbian-firstrun-config.service#L9
     

    Probably best to keep conversation here for now.  Mostly we use issues in GitHub for major bugs / problems