- a CLI image might have panfork or mesa, but not glx-mesa, mesa-utils, chromium, glmark which depend on x11/wayland
- this makes mesa-vpu useful for eg GBM applications
- only affects systemd-networkd-using builds (MINIMAL images?)
- does NOT affect NetworkManager
- this allows network administrators to give out IPv6 addresses over DHCPv6 based on the MAC address (which should be stable) instead of systemd's own notion of it's "DUID", which is based on the machine-id and changes on every redeployment
- one is actually general fix - recommened installation of library before installing rockchip-multimedia
- second is holding package before running upgrade as it wants to pull older library from kde repositories
- remove KDE Neon base files upgrade pin
Establish some consistency with extension logging. Some extensions use another format:
display_alert "message" "${EXTENSION}" "info"
These were *not* adapted to this new schema.
- Use resolved no matter what manages the network (networkd or NetworkManager)
- Use resolved.conf.d/ directory to set DNS as recommended by resolved itself
- In armbian-firstrun, remove config specific to mvebu64|mt7623 since this is now done by default
This variable was originally introduces for the board "Espressobin" (mvebu64): 38db0b55f9
Use a hook in the mvebu64 and mt7623 family config to set ignored devices for NetworkManager instead.
- Rename extensions with "net-*" prefix
- Put the extensions into their own folder
- Split off time sync packages into their own extensions to be able to be used separately
- Put their config files into directories instead of using inline `cat <<- EOF >`
- Move some other NetworkManager related stuff into the extension
- Remove unneeded steps
- Install iproute2 by default on all images (for the `ip` command)
- use Chrony with Network Manager
- use timesync with systemd-networkd
- use NetPlan with Network manager only
- move command-not-found to CLI image only
- improve firstlogin ip detection
Firmware package was incorrectly marked as machine dependent.
This was fixed in radxa-pkg/aic8800#12, causing the file name to change.
Signed-off-by: ZHANG Yuntian <yt@radxa.com>
- I had worked this before AF sent his oneliner, but I forgot to PR
- Should be the same, except avoids sadness when trying with the wrong kernel/branch
* main-config: fix: avoid errors when BRANCH contains a dash; convert to underscore
* rockchip64_common: shellfmt, no changes
* rockchip64_common: move SERIALCON defaulting logic to a (verbose) hook for flexibility
* config: allow to build BRANCHes not listed in KERNEL_TARGET as long as the config is valid
- useful for `collabora` and other experimental kernels, we don't want to have to add it to each individual board's KERNEL_TARGES one by one
- but we don't want to allow typos in BRANCH to emit very strange unrelated errors
* extensions: mesa-oibaf extension by @monkaBlyat - mainline mesa PPA for Ubuntu
- does nothing on Debian
* extensions: (v3) amazingfated-rk35xx, now `rk-multimedia-amazingfate` - panfork-free
- simply skips if not on Jammy
- deploys Chromium + Widevine if desktop
* rockchip-rk3588: introduce `vendor-boogie-panthor` experimental BRANCH/kernel
- original: https://github.com/hbiyik/linux-rockchip.git (branch `rk-6.1-rkr1-panthor-v6`)
- I picked the commits on top of clean armbian/linux-rockchip `6.1-rkr1` as of 2024-04-01
- At https://github.com/rpardini/armbian-linux-rockchip-rk3588/tree/armbian-rk-6.1-rkr1-plus-boogie-panthor-v6
- Diff: https://github.com/armbian/linux-rockchip/compare/rk-6.1-rkr1...rpardini:armbian-linux-rockchip-rk3588:armbian-rk-6.1-rkr1-plus-boogie-panthor-v6
- rockchip-rk3588: introduce `boogie-bsp` BRANCH
- rockchip-rk3588: copy linux-rk35xx-vendor.config into linux-rk35xx-boogie-bsp.config
- rockchip-rk3588: update linux-rk35xx-boogie-bsp.config, no changes
- rockchip-rk3588: linux-rk35xx-boogie-bsp.config: `CONFIG_DRM_PANTHOR=m`
- rockchip-rk3588: linux-rk35xx-boogie-bsp.config: convert to defconfig
- rockchip-rk3588: rename to `BRANCH=vendor-boogie-panthor` for "clarity" (lol)
- rockchip-rk3588: vendor-boogie-panthor: force SERIALCON, full firmware (for blob needed for panthor) & mesa-oibaf extension
- rockchip-rk3588: vendor-boogie-panthor: enable amazingfated-rk35xx extension sans-panfork
* using the configured volume group name
* added LVM support
* ensuring /boot never on LVM volume, created hook to setup root device
* preparing root device via extension, not assuming any particular partition for root
* using tab spacing
* using global parameter to require a boot partition
* using boot require, moving cryptroot code to extension
* adds crypt image suffix
---------
Co-authored-by: rafael <rvalle@privaz.io>
* added cloud-init support
* removed compymods, not required for our use case and not available in all distributions
* using space instead of tabs
* added template with typical use-cases and link to docs
* typo
---------
Co-authored-by: rafael <rvalle@privaz.io>
- new VHDX output format (for generic Hyper-V on Windows 10/11/2019/etc)
- it is always stored (no compression) in a .zip file, to avoid sparseness errors
- when building, transfer the .zip file over to Windows, and uncompress it there (not on WSL2 itself/Linux/other machine)
- only Azure wants the static, 1024-aligned original VHD images (and doesnt support VHDX?)
- new VHDX output format (for generic Hyper-V on Windows 10/11/2019/etc)
* Remove create_desktop_package.sh for rk3318 board from
config/optional, clearing the whole directory tree
* Add an extension to implement serverflags workaround
for X.Org and Lima driver not being autodetected
* Fix rk3318-box and rk322x family to use extension in place
of 40-serverflags.conf bsp file
- this extension is _100% optional_ and shouldn't adversely affect any builds if not enabled
- requires `UEFI_EDK2_BOARD_ID` to be set in board file, so we know which UEFI/edk2 build to use
- it finds the latest edk2 version from GitHub automatically (currently `v0.9.1`)
- it downloads (and caches) the correct edk2 build image automatically
- if forces certain aspects of the image:
- must use GPT partitioning
- must NOT use a separate /boot partition
- it _disables_ the building and deploying of u-boot _completely_ (thus blobs etc are from edk2)
- it creates a GPT `"uboot"` partition pointing to edk2's FIT, required by SPL
- this extension:
- automatically enables 'grub-with-dtb'
- automatically enable 'initramfs-usb-gadget-ums', to compensate for lack of ums/rockusb since we dont have u-boot anymore
- this optional extension adds an initramfs script that:
- enumerates and filters all block devices
- exposes each device as an UMS (USB Mass Storage) in an USB Gadget
- loops forever with info (board never boots)
- the idea here is to compensate for UEFI's lack of "ums" or "rockusb" mode that's present in u-boot
- it also allows to expose USB/NVMe devices that might or not be detected by bootloader, if the kernel works
- this should make `09_linux_with_dtb.sh` work across all RELEASE's, `sid` and `mantic` included
- extra: if `grub-mkconfig` (`update-grub`) fails, show all involved source files
- requires `KHADAS_OOWOW_BOARD_ID` set in board file (see next commit)
- always produces xz-compressed images, so this automatically disables `COMPRESS_OUTPUTIMAGE`
- uses `xze` script from Khadas, forcing `IN` and `OUT` env vars so it's not confused by fd 1
- to use, add `EXT=image-output-oowow` parameter to build
- to get into oowow:
- VIM3/VIM3L:
- download oowow SD card image from Khadas:
- VIM3: https://dl.khadas.com/products/oowow/system/vim3-oowow-latest-sd.img.gz
- VIM3L: https://dl.khadas.com/products/oowow/system/vim3l-oowow-latest-sd.img.gz
- write image to SD card, use BalenaEtcher or similar
- insert SD card into board (and remove NVMe if present and bootable)
- boot board into Upgrade mode, see https://docs.khadas.com/products/sbc/vim3/install-os/boot-into-upgrade-mode
- oowow should be running now
- recommended: go into Advanced and reset to factory defaults, so MCU, PCIe/USB3 etc is reset to defaults
- VIM4/VIM4N/VIM1S/Edge2: those have oowow in SPI from factory, check out the manual
- there's a few ways to use these images with oowow:
- Using External media
- prepare media (USB), format it with ext4 or fat, copy produced oowow.img.xz to it
- for ease of use, rename the image file, so it begins with the board-id (`vim1s-/vim4-/edge2-` etc)
- boot board into oowow (see oowow's manual)
- insert media into board
- exit wizard, use "Write image to eMMC", browse to "../"
- change from "XXXX only" to "All" if you didn't rename the image
- choose image file and write
- (remove SD card if using one) and reboot
- Via network (Ethernet or Wi-Fi)
- boot board into oowow
- plug in Ethernet cable or connect to Wi-Fi (see oowow's manual)
- set the firewall mode to "allow" in oowow's Network Settings (see oowow's manual)
- obtain the IP address of the board in oowow (usually shown on top of the screen, or see manual)
- from a remote machine, use curl to upload and write the image to oowow's eMMC, example:
- `curl -L <ip_address>/shell/write | sh -s - <image_filename>.oowow.img.xz`
- reboot board
- From the Internet (one day)
- when Khadas publishes Armbian oowow images to their HTTP server
