IRC channel logs
2024-01-14.log
back to list of logs
<lrvick>Okay, it is failing because it tries to overwrite /etc/resolv.conf to 1.1.1.1. <lrvick>No internet access should be happening within this build, so I am unsure why <lrvick>/etc/resolv.conf is immutable within docker so this should fail, but I don't know why it is happening at all <fossy>ah; etc/resolv.conf is changed for the mode where --external-sources is not used, and so we need etc/resolv.conf for when we download distfiles within the live-bootstrap environment later on (but obviously, you are not doing that) <fossy>best way to fix this is probably to pass through EXTERNAL_SOURCES into bootstrap.cfg and put the addition of resolv.conf in a conditional <fossy>untested but its pretty simple <stikonas>hmm, kaem uses more memory than I expected... <stikonas>running mescc-tools-mini-kaem file ends up using about 10 MiB of RAM <stikonas>hmm, I guess we reserve long buffers to store commands and their args <lrvick>giving it a shot now. fossy == fosslinux for the git --author? <lrvick>seems reasonable to just make that configurable <lrvick>live-bootstrap building with --docker now working in my branch. Will make a PR if there is any interest. <lrvick>For my own use case I will want to build the seeds myself and inject them, and avoid using the python script, but this will be a good baseline control if nothing else. <fossy>lrvick: it would be nice to have. the more environments it works on, the greater robustness that the project has (usually) (unless its a dumb environment, but docker isnt)_ <stikonas>ok, I think I know why kaem misbehaves with exit codes... <stikonas>it's probably because I didn't bother making a duplicate of program code itself when forking <stikonas>which wouldn't matter if it only runs execve <stikonas>but kaem does more between forking and execve <stikonas>so global variables and in particular malloc linked list gets corrupted <stikonas>now it gets stuck somewhere in M2-Mesoplanet when building mescc-tools-extra... <stikonas>in the meantime I think my last commit fixed mes-m2 <stikonas>it now sucessfully ran mescc to on crt1.c <stikonas>and M2-Mesoplanet hang fixed too... so posix-runner now can run stage0-posix (minus kaem-optional-seed) <stikonas>and mescc runs for a while, though somehow lib/mes/assert_msg.c failed to build after 20 or so other files built <stikonas>maybe I should retry with my latest fix that fixed M2-Mesoplanet... <stikonas>hmm, that file does build if I build it first <stikonas>rickmasters did mention that mes does some strange things file files being opened multiple times... So maybe it's that <stikonas>ok, with some small hack that still needs investigation I managed to use mes-m2 to build mes on UEFI/x86_64 (hack was restartign mesclibc build from the point of previous failure, so needed a few runs to build all of it) <stikonas>mes itself doesn't run at all, probably because mescc emits non position independent code on x86_64... <stikonas>(though the same binary runs fine back on Linux) <stikonas>janneke: I think we need to fix it on mes side <stikonas>if we want it to run using posix-runner kernel <stikonas>(should be easier than trying to figure out how to setup virtual memory and page mappings...) <janneke>stikonas: how is mescc's code position-dependent, don't addresses get filled-in only at the hex2 stage? <janneke>(not that patching mescc would be problematic, just curious) <stikonas>janneke: addresses are filled in hex2, but some of them are relative to base address <stikonas>so the binary has to be loaded at base address <stikonas>the way posix-runner works is it asks for some memory from UEFI (basically malloc) and it will get some segment but we have no control over where it will be <stikonas>so e.g. mes might be compiled with --base-address 0x08048000 <stikonas>so let's say some label (global variable) might be say at 0x08148000 <stikonas>and mes would have something like mov rax, 0x08148000 <stikonas>but we can only load the binary at "random" address that we got allocated, it could be 0x12345678 <stikonas>so the real address of that global variable would be 0x12445678 <stikonas>Linux kernel solves this by using Virtual addresses and MMU <stikonas>what M2-Planet now does (since maybe a year or 2 ago) is rather than using absolute addresses <stikonas>it loads stuff relative to instruction pointer <stikonas>so mov_rax, &label becomes lea_rax,[rip+DWORD] %label <stikonas>and that number is then no longer absolute address (&) but is relative address (%) <stikonas>I guess in normal assembly it is "lea rax, [rip+label]" <stikonas>(assuming I can find out all the places where it is emitted) <stikonas>maybe I could try to implement some paging... <lrvick>Okay just did two back to back container builds from 0 on two different systems and afaict the only non-deterministic thing is the /usr/lib/python3.8/__pycache__ folder which I assume I can just nuke safely. <vagrantc>janneke: oh, mes was removed from debian testing due to failing to build on armhf :( <vagrantc>i kept meaning to write to bug-mes but ... well ... here we are ... <vagrantc>same issue with 0.26 ... not sure if i checked 0.25.x <stikonas>so if it gets fixed, it will be automatically reinstated? <vagrantc>i also have some packaging of m2-planet which maybe i should upload to debian as well <janneke>yeah...but we might need an armhf patch before we release? <janneke>i haven't checked if 0.25.1 builds with armhf, but if 0.26 doesn't... <vagrantc>riscv64 "just" has a single test suite failure <janneke>there's nothing arm specific in 0.25..0.25.1...0.26 <vagrantc>so it seems gcc builds of mes are now the obscure codepaths :) <vagrantc>janneke: i'll follow-up to bug-mes with links and whatnot <janneke>vagrantc: thanks, i'll have a look at the arm segfault <vagrantc>it might also be perfectly valid to abaondon some codepaths <stikonas>well, arm might at some point be replaced with aarch64... <stikonas>well, stage0-posix only has aarch64 port and no armv7 port <stikonas>and full bootstrap is only working on x86 :) <vagrantc>but yeah, unlike x86, it is not reasonable to assume you can first build the "simpler" arm32 and then use that to bootstrap up to arm64, as not all arm64 capable processors support arm32 <vagrantc>same with riscv64, if anyone is crazy enough to try riscv32 :) <stikonas>but at the very least it doesn't run on visionfive2