rpardini
-
Posts
132 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by rpardini
-
-
1 hour ago, schwar3kat said:
Can you upload the logs?
1 hour ago, rpardini said:aggregation runs before prepare_host() which of course fails due to not-yet-installed 3.9 version
Fixed in `1173864872510`.
If mirror trouble (unfortunately common recently), add `SKIP_ARMBIAN_REPO=yes`
I am impressed with Mint, the default terminal is sane and doesn't eat my emoji.
-
Thanks. I am an idiot -- testing this in Docker, of course Docker has the dependencies installed after the Dockerfile build.
Without Docker, aggregation runs before prepare_host() which of course fails due to not-yet-installed 3.9 version.
-
3 minutes ago, schwar3kat said:
env: \u2018/usr/bin/python3.9\u2019: No such file or directory
Damn, I must've messed up. /usr/bin/python3.9 should have been provided by the dependency installation. Can you upload the logs? I'll try the Docker images for Una.
54 minutes ago, schwar3kat said:I'm not sure that accommodating is perhaps the best option.
Just change supported versions should do the trick.
If the versions supported did not include una then users would know to upgrade.True, I've clearly marked commits to revert if this proves pointless / not worth it / too much more work.
-
1 hour ago, going said:
Linux OS can be anything if the versions of the commands meet the requirements
True in a way, but also not: since we manage the host dependencies (prepare_host() and etc) we need to manage these things at the release level, unfortunately.
But yeah, validating the specific python / git / bash / etc versions (just --version and linux-version compare, etc) would save us from a lot of trouble.
-
8 hours ago, schwar3kat said:
The build computer is Linux Mint 20.3 (Una) has a dedicated separate drive for Armbian builds and works well for current armbian build.
Hi @schwar3kat -- I've looked into this. Mint Una is based on Ubuntu Focal, which I had understood was no longer supported.
Turns out I was wrong -- we can't build Focal images, but Focal was (on paper) still supported as build host (!)
So I went on a "let's support Focal again" spree for your benefit.
The main culprits:
- old Python 3 version (Focal has 3.8, we need 3.9; Focal does offer a `python3.9` package which I've coerced it to use now through many indirections).
- old `bash` -- which does not support `declare -I` -- which is _very_ useful. I've removed, but with pain in my heart. `shellcheck` is not gonna be happy.
- old `git` -- which does not support a bunch of new flags I've been using, but I've worked-around it.
So please `git pull --rebase` -- you should get revision `f558a285ae21c0be3e0153234cd2852783f48ade` which should work now, save for any Mint-specific crazy that's not in Focal. 🧑🚒
-
Hi, thanks again @schwar3kat for testing.
You've hit a snag with the Python3 version. I've been using type annotations, which are not supported under all Python versions.
I have not tested this under MINT UNA -- is there a Docker image for it?
I will push fixes soon and let you know.
The actual error is (only visible on your screen, not in the logfile, see below for why):
output_lists: list[tuple[str, str, object, object]] = [ TypeError: 'type' object is not subscriptable
@going and others, ref the logging:
In this specific case (error during early configuration), the logging to file was not working as intended.
That happens because capturing stdout/stderr while at the same time possibly running an interactive program (like `dialog`) does not work.
I have further split the config into more functions, which are individually logged, so that we can get the actual error in the logs (not only on screen).
Ref the log format: it's crazy, I know, and not good yet. I will try to make it more useful / readable / complete with your feedback.
Just for info, here's what the current format means:
taking for example
--> 🐛 1: 2382876 - 2382876 - 2382876: ehBE: debug: Already set BRANCH, skipping interactive [ current ]- --> is a display_alert. All levels (even debug) are logged to the log file. Lines without it are the output of an external tool / program being run.
- 🐛 is the emoji corresponding to the logging level (debug, see below); I think I will remove these from log file since everyone hates them
- 1: is ${SECONDS} -- thus the number of seconds since the build started. (useful? I dunno)
- 2382876 - 2382876 - 2382876 : are $$, caller BASH_PID, the current BASH_PID (unuseful, unless you're debugging a terribly gnarly issue due to sub-shells. not for normal people...)
- ehBE is $- (thus the bash setopts active at that moment, again, unuseful unless you're debugging very complex things like shortcircuits, use of $(), etc etc)
- debug is the display_alert logging level (has a corresponding emoji)
- the rest is the 1st and 2nd display_alert arguments.
My proposal is to reduce this drastically just to:
--> DEBUG: (1:) Already set BRANCH, skipping interactive [ current ]and also remove all ANSI-color from the logs so it can be read without a terminal.
-
2 hours ago, Kiendeleo said:
In the meantime, is there a way to install only the necessary files to an eMMC drive and the rest to an NVME to work around this limitation?
I used `armbian-install` (nee `nand-sata-install`) for this with success.
It can use a small boot partition (/boot) on the eMMC to jumpstart kernel, but mount root in NVMe.
Take care to not overwrite SPI/MTD accidentally.
-
-
8 hours ago, usual user said:
Odroid-M1 support has just landed so will be available with 6.2.0-rc1 out-of-the-box. RGA support can be wired on top (v4l2-compliance.log), but the DMA deficiency for 32-bit addresses needs to be addressed for devices with more than 4GB of RAM.
Excellent news @usual user. I've bumped Armbian to 6.1 plus the DTS patches.
My own image at https://github.com/rpardini/armbian-release/releases/download/20221213a/Armbian_20221213a-rpardini_Odroidm1_kinetic_edge_6.1.0.img.xz
Igor has community images too, including desktops... https://github.com/armbian/community/releases (might be some 6.1-rcX still, should be updated the next few days).
Any news about ATF and u-boot?
-
On 11/2/2022 at 9:03 AM, Shaun Maher said:
Tamper with the installed image a little before attempting to boot it:
- mkdir /mnt/nvme0n1p1
- mount /dev/nvme0n1p1 /mnt/nvme0n1p1
- rm /mnt/nvme0n1p1/boot/boot.scr (this file existing seems to the petitboot parser segfault)
- rm /mnt/nvme0n1p1/boot/boot.ini (for good measure)
-
Create a petitboot kboot.conf file with suitable settings:
- echo "Armbian=/boot/Image initrd=/boot/uInitrd dtb=/boot/dtb/rockchip/rk3568-odroid-m1.dtb root=/dev/disk/by-label/armbi_root rootwait rootfstype=ext4 consoleblank=0 loglevel=5 splash=verbose earlycon console=ttyS2,1500000" >/mnt/nvme0n1p1/etc/kboot.conf
Yeah, you can convince Petitboot to `kexec` into Armbian's kernel. Probably can be done on other Petitboot boards too. By then, vendor's uboot, and vendor's kernel is already loaded, `kexec`'ing then into an Armbian mainline kernel. "It works" until it doesn't...
-
I've had great success with the new 6.1-rcX based images. Applying mmind's tree for the DTS only. Good chance we'll be able to merge this board with the rest of rockchip64 around the 6.2 timeframe, with zero patches if that DTS is merged.
Keep in mind these images don't use Petitboot "the kexec stuff" itself but does use the u-boot included in SPI (which is part of Petitboot), and require the env to skip petitboot.
-
7 hours ago, usual user said:
Out of curiosity I looked at your rk3568-odroid-m1.dtb. You still carry all the shortcomings and missing improvements that tobetter has not yet backported (like e.g. broken USB, missing SPI flash support, ...). with the posted "Add support for the Hardkernel ODROID-M1 board" series there is nothing left you need from tobetters tree. If you insist on using an outdated kernel version, all necessary backport patches can be inherited from the mainline tree. Generic mainline support is currently already more advanced than what the manufacturer offers.
No, not all -- I took tobetter's tree from the start, and just stuck with it. I'm not "insisting" on it at all. I'm 100% open to:
1) replace with clean mainline patchset against 6.x (still separate kernel deb from rockchip64)
2) unite with rockchip64, when the rest of it is at 6.1+ too. this would require .config merge too and who knows what else.
Don't hesitate to send me an -rc tag number and the patchset / .config and I'll drop it in there asap
-
15 hours ago, usual user said:
You've removed the only part I used from your image
Damn it, I can't get even one right. Do not worry, the u-boot building code is still alive in another branch. I just got no time to work it, and it's very messy not ready for release (eg is amd64 only).
That said I squashed the rest into 👉 https://github.com/armbian/build/pull/4267 against master 👈 (not armbian-next) -- someone gotta build it and review though. It should even have working overlays...
15 hours ago, usual user said:[For 6.1.0-rc1...] It also configures the hardkernel SPI flash partition layout, so fw_setenv is working for petitboot to set "skip_spiboot = false".
That's great news. Hopefully we can then move the 5.19 edge to current and add 6.1-rcX as edge, with a single patch? that'd be sweet.
-
7 minutes ago, rpardini said:
It does not carry an u-boot anymore, and uses less crazy partitioning. All blobs are from HK's SPI.
It now requires the SPI u-boot with skip_spiboot = true, https://wiki.odroid.com/odroid-m1/software/boot_sequence#bypassing_petitboot
IMPORTANT: I have NOT verified skip_spiboot = false can be set from Armbian yet. Caveat emptor!
-
2 hours ago, usual user said:
All outstanding DT patches just landed. Thus, the essential rk3568 SOC support is available out-of-the-box with the release of 6.1.0-rc1. With the exception, of course, of the board DT. The board manufacturer has no plans for mainline support in the near future. There are some efforts by the community to take the initiative, but this is only second-hand support. Only the board developer can be the authoritative source because only he knows all the details of the design. For proper mainline support, it is the obligation of the board designer to deliver a board DT as an absolute minimum requirement. Everything else can then be taken over by the community, because it is no longer board-specific and can benefit from similar development of similar boards. This fact is demonstrated with this SBC, although no mainline SOC support has been contributed by the board manufacturer, my desktop OS deployment works perfectly
Very good news about landed patches.
Tobetter's posture: shortsighted. He's also contradicting himself, having worked on board DTs for Banana boards.
2 hours ago, usual user said:or underpaid Armbian developers provide it for free
Yeah, here's an edge 5.19 version, which is a snapshot/git format-patch of tobetter's 5.19 at some point, rebased to 5.19.4 and now rolled-forward by armbian to 5.19.12.
It does not carry an u-boot anymore, and uses less crazy partitioning. All blobs are from HK's SPI.
It now requires the SPI u-boot with skip_spiboot = true, https://wiki.odroid.com/odroid-m1/software/boot_sequence#bypassing_petitboot
👆☝️
-
On 8/5/2022 at 10:20 PM, Nexus said:
Any clue on what mirror to get this/where to find it (if that is actually the issue here)?
This is most probably a bug on my side. I build with all repos and mirrors disabled (SKIP_ARMBIAN_REPO=yes) so everything is built locally, but clearly I've a bug when you don't have that option. Try with it and let me know... meanwhile I'll try to find and fix the bug.
-
On 7/13/2022 at 11:51 PM, Nexus said:
Hello. Is anyone else having issues compiling desktop images for this platform? Attached are the 2 error logs that the compile script produces. I used build files from rpardini's repository; specifically the "extensions" branch. Is this the incorrect one? Thanks for any help.
Logs producedHi Nexus. It seems you're trying to build on arm64, but my code is using the u-boot + rkbins from HardKernel, which unfortunately only work on x86 / amd64.
Also, you're better off building from "armbian/build" branch "armbian-next' instead of my "extensions" branch, which is very (very!) volatile.
-
Rock 5b test images, from armbian-next. Using vendor u-boot + patches, and vendor kernel, both straight from radxa's git
XFCE desktop with "browsers" app group
CLI
PR: https://github.com/armbian/build/pull/3984 (against master)
All work by @amazingfate I just gathered stuff and built images.
Thanks to @monkaBlyat @lanefu @piter75 @amazingfate for tests / patches etc
-
-
21 hours ago, going said:
But then the process of creating these archives in the build system is not necessary. It becomes a simple periodic manual work. Update this storage once a month
Yes. GitHub Actions workflow is setup to run everyday at 3am UTC. https://github.com/rpardini/armbian-git-shallow/blob/main/.github/workflows/main-latest.yml#L6
If you look at the GHA logs it is already working, everytime I push a commit but also everyday at 3am by itself: https://github.com/rpardini/armbian-git-shallow/actions
👍
-----
Apart from that, I am still investigating some vendor kernels (HardKernel, but also others) specially in 4.19 series, if I pre-seed the local copy with linux 4.19 shallow bundle, and then pull from that vendor's kernel tree, it comes down a lot (1.5Gb).
I suspect that is because the vendor started his kernel Git from somewhere _way_ before 4.19-rc1, and there is a mismatch during git negotiation for the fetch, and ends up pulling a lot.
@going I think you also regularly pull from "megous" repository that would be interesting to test too.
------
Another possible problem are developers/users in China which can't get to github.com for downloads.
For this case we could publish, in addition to GH Releases, also to some other FTP or rsync that we already have @Igor?
-
The reference for why this was written: https://github.com/armbian/build/pull/3476#issuecomment-1042063299
(mricon is from the Linux Foundation, who appeared after our CI was banned from kernel.org due to too much shallow fetching)
Also https://github.com/armbian/build/pull/3476#issuecomment-1042322996
-
Thanks for the attention guys. I guess I did not explain this correctly...
The shallow_kernel_tree.sh script is run on GitHub Actions (not any user machine, ever), it downloads a lot of stuff (including a 2.4GB bundle, indeed), updates it, massages it into shallow, and publishes the output.
The output is here: https://github.com/rpardini/armbian-git-shallow/releases/tag/latest
Each kernel version gets a shallow bundle (file) around 250mb each.
That output would then (later) be used by armbian/build to seed a kernel tree, downloading from GH CDNs via HTTPS, instead of pulling everything from kernel.org's (or mirrors) git server.
After seeding, pulling from the git server is very fast / small download (a few megabytes).
That way people or CI servers building Armbian will only download those 250mb + a few.
Combining all this allows us to have a small, shallow git tree, that has the tags we need, and can be kept updated cheaply, without ever fetching/cloning it using shallow, and thus does not put any load on the git server.
-
Hello, I've finally gotten around to writing the GitHub Actions based Linux Kernel Shallow git trees exporter.
It's very simple, a single shell script and GHA workflow.
It prepares shallow bundle (and ready-to-go .tar too) everyday on a schedule and publishes to GitHub Releases.
Please take a look https://github.com/rpardini/armbian-git-shallow - theres a README that shows how to use the bundles outside of Armbian.
If this is a good idea, I'd move it to armbian/kernel-git-shallow in GitHub.
And then I'd start using those in armbian-next first as a test ground.
I mention I few people I know are interested in the subject @Igor and @going but of course everyone welcome to pitch in
Thanks
(PS: No idea why I'm required to tag a board for this post)
-
Ok here's a new version, 5.18-rc7 from tobetter's tree. Still very early days.
tobetter is doing a fantastic job this time around, keeping his tree rebased properly this time.
This version has working NVMe (!), panfrost somewhat works, some hangs when panfrost is used.
eMMC does NOT work in my experience, it hangs the machine if trying to use it. use SD card.
unzstd, burn to SD, boot either with or without holding the button. (it should NOT go into or through Petitboot either way, instead the SPL in SPI should find and boot uboot in the SD card, or with button boot all blobs from SD).
(4.x stuff still does not have HDMI, I've no idea why, it's otherwise stable, but I won't post it here since most people just assume it does not work at all if HDMI does not work)
armbian-next development
in Advanced users - Development
Posted
Yep -- same theme as always: `master` swallows errors, `armbian-next` bitches about them and stops.
In this case, indeed we can ignore the error, or even skip the clock sync completely it if we detect ntpd already running.
This is to show, literally everything can fail. This piece of code needs conversion to something more sane, like using `findmnt` targeting the specific directories involved, instead of asking for the world and grepping.
🎇 👍 Thanks for the insistence!
Hmm -- this is on a different scale -- the whole patching subsystem has been rewritten, and it by design bitches a lot about "cosmetic" issues like this.
In this case it should be a warning -- not an error, but see below.
Nice, not everyone understands this.
The new tooling can also force-feed the patches back into git, rewrite the patches in-place (after putting them in git, and them out of git), auto-rebase them, and auto-migrate them across releases. (There is no CLI yet to expose these functions, but it is coming soon).
The new patching system tries to understand mbox-formatted patch files, parse / split them (using a proper mbox parser), understand each hunk individually (using a "somewhat-proper" unidiff parser, if such thing exists) and apply each separately (still using Larry Wall's `patch` utility, which is fuzzy/lenient), and report individual failed hunks.
It can also try to "recover" patches that are not mbox-formatted by doing "Git archeology" looking for the (Armbian) commits that introduced that patch, across releases, with varying pitiful levels of success.
The .md "log file" that is produced during a build should include Markdown patching summaries with some information about the process and the patches. This one I've been working, mvebu-edge, https://rpardini.github.io/linux/armbian-next-mvebu-6.1-20230106.html and mvebu-current https://rpardini.github.io/linux/armbian-next-mvebu-5.15-20230106.html
Unfortunately there's a _thousand_ different ways that mbox files can be mangled, I've been resorting to some heuristics to find the problems, and every day I find more.
- Look at this one: https://github.com/armbian/build/pull/4652#issuecomment-1373049039 ("FFrom"...)
- @going this one is a head-scratcher, I've been working on a "number of magic markers has to match the number of mails in the file" validation and found this friend here: `sunxi-6.1/patches.megous/Add-README.md-with-information-and-u-boot-patches.patch` (a patch that... contains a patch?) -- it is of course inoffensive problem.