• Content Count

  • Joined

  • Last visited

About tparys

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. So, started playing around a bit. Mostly just mocking up ideas. The script currently is recursively driven by a directory system. When it hits a script, it simply executes it. Should be pretty easy to extend. Just drop a script in place and it should use it. I mulled over how to "name" the various scripts and directories, and eventually settled on using gettext, which also provides internationalization support as well. Basically takes the relative menu location like "/system/firmware" and "translates" into the appro
  2. armbian-reconfig As the old joke goes. There's only two things hard in computer science. Naming things Cache invalidation Off by one errors I'm probably going to take a stab at it this weekend. More to follow (hopefully).
  3. Some additional information for the curious ... The ARM EABI (armel) port targets a range of older 32-bit ARM devices, particularly those used in NAS hardware and a variety of *plug computers. The newer ARM hard-float (armhf) port supports newer, more powerful 32-bit devices using version 7 of the ARM architecture specification. The 64-bit ARM (arm64) port supports the latest 64-bit ARM-powered devices.
  4. Any chance this might work for you? $ sudo chsh -s /bin/zsh <username> And logout / log back in.
  5. Armbian is little more than a stock Debian/Ubuntu installation with the aim of providing recent kernel, bootloaders, and some quality of life userspace customizations. None of those seem needed for a docker image. Maybe start with the upstream image of whichever version you're using for your Orange Pi? If you do need certain things from Armbian, you can always copy the apt configuration from /etc/apt/sources.list or sources.list.d into your Dockerfile and go from there.
  6. For what it's worth, from what I've seen, the M4 SATA hat uses the same PWM control that the M4 metal case does. And the kernel can control it just fine via overlay on the modern kernel. Just need to define a fan on that PWM channel, and attach it as an active trigger to the CPU. Might still need some tweaking, but could try and finish it up and submit it as part of the kernel overlay?
  7. I'm not aware of any direct NFS support in u-boot. Though that support may exist in recent versions. However, initramfs-tools does support NFS, and you may consider using that instead. So, you may want to make a local boot partition, even if your root is NFS. And all you'd need is u-boot, your kernel, initramfs, and DTB. You might start looking into the "nfsroot" and "ip" options of initramfs-tools:
  8. I suppose my question was less where you would run it, and rather what exactly you would want to test. Unit tests are great for functional libraries with known inputs/outputs, but are somewhat trickier with user interfaces. Testing the individual scripts should be more possible if you're looking for actual run products (eg - changes to /etc/apt/sources, or edits to config files).
  9. I don't mind taking a swing at a proof of concept. Might not be immediately. Still trying to ID an issue on my M4V2. Also not sure what sort of CI processes or Docker deployments you have in mind.
  10. So I'm not super familiar with OMV, so take al this with a grain of salt. However, I find it easiest to set static IP's via ifupdown. Based on the "source-directory" line you might just put the below in "/etc/network/interfaces.d/eth0", and enable via "systemctl enable networking", and see if that works for you. iface eth0 inet static address gateway Another option for NetworkManager is to use the "nm-connection-editor" application. There's a lot of options for specifying network configurations. I'd check that
  11. As a fun little hack, here's a little example wrapper for the dialog program. Mark it executable, toss it in /usr/local/bin, and fire up armbian-config. Obviously delete it afterwards. don't leave it there. That's probably a bad idea. But might work as a brief tech demo of what an X11 driven armbian-config might look like ... dialog
  12. Best practice to include "armbianmonitor -u" and leave at top of your post. What files do you have in /etc/network/interfaces.d? Is the "network" service started / running?
  13. So, there are GUI based dialog frontends. Where you would do something like this in dialog: $ dialog --menu "Choose an option" 0 0 0 a argle b bargle Or whiptail ... $ whiptail --menu "Choose an option" 0 0 0 a argle b bargle You could use a different frontend like zenity to do something similar. Obviously the arguments would change: $ zenity --title "Choose an option" --column tag --column Description --list a argle b bargle If you could distill it down to minimum information required to populate either list, you could have a bash
  14. More digging. Looks like folks have gotten the M4 (v1) headphone jack working in the past. At minimum, you may have to fiddle with ALSA settings a bit before it does much: I was not able to get the headphone jack working, but HDMI is working for me. So at least most of the audio subsystem is intact. Had to set the default audio device to HDMI via pactl before I got anything out of it though. Both I2S controllers on ff890000 and ff8a0000 are still screaming in