IRC channel logs
2025-01-04.log
back to list of logs
<oriansj>clemens3: thank you for that bug report, I'll try to fix what is in savannah and make sure the README has the correct instructions too <stikonas>oriansj: keep in mind that I pushed a small commit to github <stikonas>I think just adding --recursive, but pull it first <oriansj>oh and my 2024-2025 git only gpg key has been added to github <matrix_bridge><Lance Vick> or maybe I am a dumb dumb and there is some alternative solution I totally missed, which is entirely possible <matrix_bridge><Andrius Štikonas> Lance Vick: yeah, this is a missing feature... <matrix_bridge><Andrius Štikonas> we have to apply some workarounds after extracting mes too <matrix_bridge><Andrius Štikonas> but required syscall is probably missing from M2libc and kernels too <matrix_bridge><Andrius Štikonas> when does that extraction of yours happen? <matrix_bridge><Andrius Štikonas> (oh it must be because this is live-bootstrap source) <aggi>plasma41: "slibtool is a libtool implementation written in C" <aggi>it's faster, than libtool, i managed to enforce static-linking with it, and it defines another sanity-check for autoreconf <aggi>i got a suspicion why most distributions do not autoreconf while packaging, and why none would provide static-linking <aggi>to my understanding, autotools and [s]libtool were designed to simplify compile-time configuration such as cross-compilation and static-linking <aggi>it's confusing if configure.ac injects hard-coded paths to -I/usr/include and -L/usr/lib when sysroot resides elsewhere, some checks utilize pkg-config, others $PKG_CONFIG, others don't at all, the configure switches vary <aggi>up until recently, slibtool picked up some macros from libtool, that i removed now; some packages ship their own m4 macros, others need a specific variant of those for any autoconf version <aggi>this significantly complicates re-producibility of builds further <aggi>most of related problems are trivial to repair, it is hitting hard however if various cross/compilation variants are involved, for hundreds of builds, with dependencies among them <aggi>the issue i am having with GNU isn't their license, it's quality in particular with things like autotools, which imply a vendor-lock against GNU <aggi>and the fact, the time and work i am investing into this, is uncompensated, while their license enforces copy-left without any compensation <aggi>and it is not possible to distinguish whom work is shared with, with those who play fair, and excluding those who foul play <aggi>"American digital companies earn a lot of money in the EU and pay hardly any taxes" <aggi>many bootstrapping issue are caused by anti-competitive habits <aggi>the Intel roadmap abandoning UEFI/csm is a full scale escalation of trade war <aggi>the autotools madness is a result of the "unix wars" <aggi>although i got bundled a complete i486-tcc-linux-musl.iso with development utilities, intel prohibits booting it on many of their laptops without CSM since 2017 <aggi>although coreboot/seabios exist, such cannot be flashed onto most laptops <aggi>plasma41: it's easily found online <aggi>integration of it into any packaging system isn't trivial always <aggi>and for linux-2.x ABI a few simple patches are required <matrix_bridge><Lance Vick> Andrius Štikonas: Can you link to said workaround? Surely it cannot be as bad as mine which is borrowing untar from debian. <stikonas>sure, it's in live-bootstrap mes script, let me find it <gabif>hi everyone, i've been looking into and tried to use live-bootstrap in the last couple of days <gabif>so far i learned that my system reboots when the bootstrap process tries to kexec into fiwix <gabif>it worked with --qemu, but i didn't try to do anything further with the result yet <stikonas>gabif: also, what kind of system are you using? <stikonas>latter might not work for kernel bootstrapping <gabif>No, "Starting /boot/fiwix.ext2 at addr ..." and it reboots after in 3-4 seconds <stikonas>I think Googulator migth know better but UEFI with CSM often has issues with memory maps <stikonas>for UEFI/amd64 in principle we should write its own "kernel" bootstrap chain <stikonas>and there is some early code but it's not finished <gabif>i didn't look at what's already done about it <gabif>i'd expect "builder-hex0" stage to be not too hard <gabif>a stage similar to fiwix could be much more challenging <stikonas>it's quite different even in early stage, some stuff is easier, some is harder <stikonas>we basically have stage0-posix, i.e. port of all those early binaries to UEFI <stikonas>then I started working on some kind of posix kernel wrapper based on builder-hex0 that still runs under UEFI <stikonas>you are constrained by UEFI until you shut down Boot Services... <stikonas>but once you shut down boot services, you don't have easy I/O <stikonas>so either you accept what UEFI imposes on you (in particular memory management) or you need to write your own code to deal with graphics framebuffer and some FS stuff... <stikonas>nothing undoable, just didn't have enough people working on it <Googulator>Some UEFIs do put a reserved memory region around the 1GiB mark in CSM mode, which breaks builder-hex0's expectation of a flat memory block between 0x100000 and the start of the MMIO area <aggi>the tinycc/linux2.4 seems to work without problems atop some uefi/csm on a hp t620 thin client tested with <aggi>i'm still occupied with cleanup tasks to prepare for re-write of packaging compatible with live-bootstrap <aggi>with an old thinkpad t40 e100pro ethernet is detected, ide, sata, smp, for the t620 the gigabit ethernet is not detected <aggi>i'll try to backport a few important drivers to linux-2.4, to keep this broadly compatible <aggi>some rtl8188eu[s] wifi usb dongle would be neat, maybe an asix usb-eth dongle, some hardware which is readily available <aggi>don't know yet if and how a linux2.4 could best be integrated into kernel-bootstrap seemlessly <aggi>if tccboot was utilized, this imposed some intermediate limitation (nosmp at the stage linux24 could not be compiled AoT to process related 16bit real-mode asm yet) <fossy>urgh, the memory map problem rears it head again <fossy>and its not going to be easily solvable lol