Jump to content

Igor

Administrators
  • Posts

    14681
  • Joined

  • Last visited

Posts posted by Igor

  1. 59 minutes ago, akabulous said:

    radio silence for over a week seems completely inappropriate

     

    We understand the concern, and we appreciate the effort put into testing and documenting the issue. At the same time, it is important to understand the realities of the embedded Linux ecosystem. Armbian supports a very large combination of SoCs, vendor kernels, boot chains, and downstream modifications across several hundred boards. Security response and validation in this environment is significantly more complex than in standardized desktop/server distributions.


    Explained here:
    https://github.com/armbian/build/issues/6937#issuecomment-4366571379

     

    This is not a matter of ignoring the issue, but of limited engineering resources, kernel fragmentation, and the high cost of validating fixes safely across multiple platforms. Project can only finance security from your contributions https://github.com/sponsors/armbian volonteers or sponsors. Until none is taking this seriously, there is little what existing team members can do.

     

    We already attempted mitigation work on one of the most widely used kernel branches:

    https://github.com/armbian/linux-rockchip/pull/475 but even targeted fixes require substantial testing effort and may (i am sure it will) introduce regressions on affected hardware families.

     

    Current resources barely sustain even our regular release and maintenance process:
    https://docs.armbian.com/Process_Release-Model/

     

    For users who need receiving upstream fixes faster and are willing to accept a higher risk of regressions on hardware feature breakage, there is always an option to switch to rolling/daily builds, where fix may already be available:
    https://docs.armbian.com/User-Guide_Armbian-Config/System/#rolling

    Tradeoff between stability, validation cost, hardware compatibility, and update speed is unfortunately a sad reality of embedded Linux maintenance. 

     

  2. For Ubuntu Resolute desktops you need to build from this branch:
    https://github.com/armbian/build/pull/9683

    It is a matter of days when this will be merged. You can speed this process by reviewing the code.

     

    P.S.
    We lack 1-2 beefy arm64 servers or 30-40k $ and unknown $ for storage space as we would need to upgrade from free storage which is limited to 1000 artifacts in order to provide more build combinations. We are far away ...

  3. 52 minutes ago, DavidFajardo said:

    Running VirtualBox on Armbian is generally not a good fit for what you’re trying to do. Armbian is primarily designed for ARM-based single-board computers, and VirtualBox is built with x86 hosts in mind and relies on kernel modules that are not well-supported (or sometimes not available at all) on ARM kernels like the one in your chosen Armbian image.

     

    Generic aarch64 or x86 image has all needed support for most comon virtual environments. On a side we provide cloud images, optimized to run inside KVM / QEMU virtualized environment - super lean kernel.

    https://armbian.com/boards/uefi-arm64
    https://armbian.com/boards/uefi-x86

    Look for cloud kernel images.

     

    52 minutes ago, DavidFajardo said:

    especially on boards like the Orange Pi 5 Plus.

     

    Here it can only be a problem if host (Orangepi) supports qemu or not. I don't run it here but I think it must just work.

     

    52 minutes ago, DavidFajardo said:

    if you specifically want VirtualBox, you’ll have a much smoother experience running it on a standard x86 Debian/Ubuntu system rather than Armbian.


    There won't be any difference compared to standard Debian / Ubuntu. Armbian is more polished in general, comes with several important improvements.

    Securing support for virtual targets is relatively easy compared to any custom hardware. And this was done long time ago. We use Armbian UEFI and QCOW2 virtual images to drive our infrastructur and also automated testing, but of course we target KVM / Quemu not Virtualbox. Which anyway can run normal image. Our runners and cloud services mainly run Armbian Noble cloud.

    Our website (dual core x86 vps):

    image.png

     

    www:/boot:% du -h vmlinuz-6.18.10-cloud-x86
    15M    vmlinuz-6.18.10-cloud-x86

    + 17M for modules (normal image has 150-200M for modules, for things you never need in virtualized environment)
     

     

    52 minutes ago, DavidFajardo said:

    If your goal is to run Home Assistant without containers, a more reliable approach would be to either run Home Assistant OS directly on supported hardware, or use a lightweight hypervisor that works well on ARM (such as KVM/QEMU


    Yep, that's the best path for this use case.

  4. 3 hours ago, KAHrel said:

    After deleting it, it detects it, but my Android system stops working.


    When SPI is erased, the board falls back to the bootloader on the SD card. If you want to run Armbian, or Linux in general, the bootloader often needs to be updated - in this case on SPI. This can be done with armbian-install.


    Android support is not verified and is outside the scope of Linux maintainers. It may continue to work, or it may break.

  5. 1 hour ago, kris777 said:

    there are no entries for: I2S

     

    This likely means the I2S overlay doesn’t exist yet. Someone would need to implement it and add it upstream (or just here to Armbian build framework). You can try enabling it manually via the Device Tree editor: https://docs.armbian.com/User-Guide_Armbian-Config/System/#device-tree-editor

     

    No guarantees it will work — hardware descriptions are often incomplete or inaccurate, and that’s outside our control.

  6. https://actions.armbian.com/?repo=armbian.github.io

     

    Here anyone can monitor ... but the real problem is capacity to fix problems. Not knowning them. We have too many problems on the to do list :(

     

    2 hours ago, bedna said:

    Ignore this if all is ok.


    It is not O.K., but also not a critical problem. This script is making a cache for this package which is needed in critical operations. Where it can't fail. This is why this was made in 1st place. We can't rely on upstream infrastructure.

  7. 14 hours ago, XXXBold said:

    Which image?


    Gnome (wayland) desktop with kernel 6.18.y
     

    14 hours ago, XXXBold said:

    Would using the CLI version also work

     

    Probably this way?


    apt install mpv

    mpv --hwdec=auto test.mkv

     

     (+) Video --vid=1 (*) (hevc 1920x816 25.000fps)
     (+) Audio --aid=1 --alang=mul (*) (aac 2ch 48000Hz)

    AO: [alsa] 48000Hz stereo 2ch float
    VO: [gpu] 1920x816 yuv420p

     

    But something is still missing ... not hw accelerated. Sorry, not an expert here. I am happy when Chromium says it.

  8. What's new in armbian-config desktops

    Pick how much desktop you want — at install time and after
    Three tiers (minimal / mid / full) instead of one monolithic install. Minimal = DE + display manager + a terminal (~500 MB). Mid adds a browser and everyday apps (~1 GB). Full adds office + creative tools (~2.5 GB). And you can move between tiers later — armbian-config knows the delta and only adds or removes what changed, no reinstall.

    Clean uninstall, every time
    Every install records a manifest of exactly which packages it added. Removal undoes only those — packages that were already on the system before you installed the desktop stay put. No more "I uninstalled XFCE and lost half my system."

    One YAML per desktop, no per-distro hacks
    Each DE is a single declarative file in tools/modules/desktops/yaml/. Adding or maintaining a desktop no longer means editing scripts; you describe what you want and the engine figures out releases, arches, browsers, and overrides. Adding a new desktop is a YAML edit and a parser smoke test, not a hunt through bash.

    Same desktop, every supported distro and arch
    Per-release and per-arch overrides handle the awkward edges: missing packages on armhf, the riscv64 ports that lag behind, the package that got renamed in Ubuntu noble. Same YAML works on Debian bookworm/trixie and Ubuntu noble across amd64 / arm64 / armhf / riscv64.

    Smart browser selection
    The literal token browser resolves to the right package per platform automatically — Chromium where it exists, Epiphany on platforms where Chromium is broken, Firefox-ESR on Debian riscv64. No more bug reports about "Chromium won't install on RISC-V."

    Custom vendor archives, done right
    Optional repo: block per DE with full support for: signed-by GPG keyring (no apt-key), per-release suite paths (e.g. SpacemiT's per-snapshot bianbu archive), multi-suite fan-out (one archive, six deb lines for security/updates/customization channels), wider component lists than main, and APT pin preferences in the same place. Removed cleanly on uninstall.

    Auto-login that doesn't trash your config
    Enable / disable autologin for gdm3, sddm, or lightdm via in-place sed edits — your WaylandEnable=false and other customizations stay intact. Branches on ID=ubuntu from /etc/os-release, so it writes to the right file (Debian's daemon.conf vs Ubuntu's custom.conf) without guessing from the codename.

    A weekly AI driven self-audit catches drift
    A scheduled workflow scans the YAML matrix against armbian/build's supported releases and the live Debian/Ubuntu archives — flags releases not yet covered, flags packages that no longer exist upstream — then opens a draft PR with proposed YAML fixes. Dead packages and missing releases stop accumulating silently.

     

    armbian-config --api module_desktops


    image.png

     

    User documentation:

    https://docs.armbian.com/User-Guide_Armbian-Config/System/#desktop

     

    image.png

     

    image.png

  9. 6 hours ago, evilbunny said:

    I don't understand is why you have a mirror still listed

     

    Open source projects like ours operate with very limited resources, and infrastructure such as mirrors is maintained on a best-effort basis.

    We’re aware that things are not always perfect, but addressing this properly requires dedicated maintainers - something we never had.

    If you’d like to help improve the situation, we’d genuinely welcome someone stepping in to take ownership of this part of the infrastructure. Improving scripts to make this information correct and other things that are missing ... Perhaps contanting mirror owner would already be a solution.

     

    6 hours ago, evilbunny said:

    I've been an apt/Debian user long enough to have a reasonable idea how mirrors work

     

    I understand - but our mirror system isn’t a standard Debian-style setup. The “empty mirrors” you’re seeing are a cosmetic problem. Only status isn’t automatically pruned yet, so entries can remain listed after they’re no longer active.

     

    This does not affect users: traffic is routed through apt.armbian.com and dl.armbian.com, which only serve from working mirrors. What’s missing is automation to keep the public listing in sync - not mirror functionality itself.


    One of those https://actions.armbian.com/?repo=armbian.github.io needs further development.

     

    6 hours ago, evilbunny said:

    Perhaps more to the point, is this a temporary technical glitch or permanent removal of Armbian packages?

     

    Our rsync server works: rsync -av rsync://rsync.armbian.com/dl/

     

    I have no clue as this mirror is not under our direct control. 

     

    Edit: I sent email to administrator of AARNet.

  10. 13 hours ago, evilbunny said:

    mirror.aarnet.edu.au is still listed on that page


    At the begginging of the page https://docs.armbian.com/Mirrors/#introduction it is written how the system works. What we don't provide on that list is current status of which are live in in sync. However you can check this at any moment:

     

    curl http://apt.armbian.com/mirrors | jq

     

    Spoiler
    {
      "AS": [
        "http://mirrors.tuna.tsinghua.edu.cn/armbian/",
        "http://mirror.twds.com.tw/armbian-apt/",
        "http://mirrors.bfsu.edu.cn/armbian/",
        "http://mirror.ossplanet.net/armbian/apt/",
        "http://mirror.albony.in/armbian/"
      ],
      "EU": [
        "http://mirrors.c0urier.net/linux/armbian/apt/",
        "http://netcup-03.armbian.com/apt/",
        "http://armbian.systemonachip.net/apt/",
        "http://mirror.hostiko.network/armbian/",
        "http://es.sbcmirror.org/apt/",
        "http://mirrors.dotsrc.org/armbian-apt/",
        "http://fi.mirror.armbian.de/apt/",
        "http://xogium.performanceservers.nl/apt/",
        "http://netcup-02.armbian.com/apt/",
        "http://armbian.nardol.ovh/apt/",
        "http://distrohub.kyiv.ua/armbian/",
        "http://mirror.vinehost.net/armbian/apt/",
        "http://k-space.ee.armbian.com/apt/",
        "http://imola.armbian.com/apt/",
        "http://stpete-mirror.armbian.com/apt/",
        "http://armbian.hosthatch.com/apt/"
      ],
      "NA": [
        "http://armbian.chi.auroradev.org/apt/",
        "http://armbian.lv.auroradev.org/apt/"
      ],
      "default": [
        "http://armbian.chi.auroradev.org/apt/",
        "http://armbian.lv.auroradev.org/apt/",
        "http://mirrors.c0urier.net/linux/armbian/apt/",
        "http://netcup-03.armbian.com/apt/",
        "http://armbian.systemonachip.net/apt/",
        "http://mirror.hostiko.network/armbian/",
        "http://es.sbcmirror.org/apt/",
        "http://mirrors.dotsrc.org/armbian-apt/",
        "http://fi.mirror.armbian.de/apt/",
        "http://xogium.performanceservers.nl/apt/",
        "http://netcup-02.armbian.com/apt/",
        "http://armbian.nardol.ovh/apt/",
        "http://distrohub.kyiv.ua/armbian/",
        "http://mirror.vinehost.net/armbian/apt/",
        "http://k-space.ee.armbian.com/apt/",
        "http://imola.armbian.com/apt/",
        "http://stpete-mirror.armbian.com/apt/",
        "http://armbian.hosthatch.com/apt/"
      ]
    }

     

  11. 5 hours ago, John Felstead said:

    but it cant find a ARMv7 image.

     

    They don't provide images for armhf anymore. Last build was 3 years ago:
    https://hub.docker.com/r/owncloud/server/tags?page=1&ordering=last_updated&name=v7
     

    We made a notice that its compatible for amd64 and arm64:
    https://docs.armbian.com/User-Guide_Armbian-Software/Media/#owncloud

    but our installer doesn't filter that out yet.

    Official Docker way, it won't work. Try something else, perhaps 

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines