IRC channel logs

<fosslinux>I'm doing bare metal testing fairly regularly as well, Christoph and Googulator, so I hope it won't break any time soon

<Googulator>fosslinux: that's good to hear

<Googulator>what system are you testing on?

<fossy>alternates between a 4th-gen Intel Gigabyte minipc, and a 7th-gen Intel Dell Latitude laptop

<fossy>i keep meaning to test my core2duo old ass laptop but haven't yet

<Googulator>good to know we can build on HW that new, if CSM is available

<Googulator>one of us will need to get some period AMD hardware, to cover that angle as well

<Googulator>interestingly, AMD still kind-of supports CSM/BIOS boot on AM5

<Googulator>but only when using a discrete graphics card

<Googulator>because no 16-bit VBIOS exists for RDNA2/3 GPUs like the ones embedded in AM5 CPUs

<fossy>my desktop is an AM4 system but it's fairly rare i'd be able to have it occupied with a bare metal build

<Googulator>right, AMD is also clearly still supporting and even releasing new CPUs for AM4

<Googulator>so even now, 4 years after Intel's announced CSM cutoff, AMD is still an option if you need CSM

<Googulator>BTW, just achieved pivot to a 64-bit kernel on bare metal

<Googulator>although it's not exactly friendly to the live-bootstrap build system

<stikonas>not friendly?

<Googulator>I used musl-cross-make

<fossy>in other news, i just pushed an lfs branch to live-bootstrap (NOT intended for merging into master) that can run jhalfs

<Googulator>& then rebuilt the kernel with a new config modified from the original using menuconfig, which requires ncurses

<fossy>(jhalfs must be run with a hand made or outside made config though as I wasn't bothered to add ncurses)

<fossy>there are some commits from the lfs branch i will cherry pick into PRs, such as a bunch of updates / rebuilds needed for glibc i think

<Googulator>oh, so same issue as here

<Googulator>ncurses is a Bravo India Tango Charlie Hotel

<Googulator>requires a custom version of autoconf to regenerate its configure script, none of our bootstrapped versions work

<Googulator>(some seem to, generating a script that seems to run OK, but then make fails)

<Googulator>as for the Linux kernel, even after installing ncurses (built via pregen configure script), menuconfig will fail unless I leave _shipped files in place

<Googulator>at least menuconfig/ncurses isn't required once you have a config file ready

<Googulator>fossy: can I ask for some feedback on my PRs?

<Googulator>#415, #418 and #421 primarily

<Googulator> https://gist.github.com/Googulator/42fff6e8771912b5b83028c283d1b33e diff for 64-bit kernel config

<fossy>Googulator: ah, yes, thanks for reminding me

<stikonas>fossy: though ideally we should add both ncurses and readline

<stikonas>currently our command line tools have very nasty command line interface that does not support readline features that everybody is used to

<fossy>yes, we should

<fossy>i just haven't yet :)

<fossy>also i didn't do pregenerated files for any opf those packages either

<Foxboron>lrvick: Ah yes, Perl is one of them

<matrix_bridge><Lance R. Vick> Was able to fix it: https://git.distrust.co/public/stagex/src/branch/main/src/core/perl/Dockerfile#L25-L31

<Foxboron>Ah yes, that works fine

<matrix_bridge><Lance R. Vick> ugly, but gets the job done and at least it is not a patch. Had to downgrade m4 to get around that issue. Now the last package not reproducible is python3.

<matrix_bridge><Lance R. Vick> Thankfully guix did a patch last week, so trying it

<muurkha>Christoph: I'm adding Googulator's comments to http://canonical.org/~kragen/sw/pavnotes2.git (hope that's okay, Googulator)

<muurkha>because I think they will be important for me to refer to in the future

<muurkha>CSM is "Compatibility Support Module" in UEFI?

<muurkha> https://en.wikipedia.org/wiki/UEFI#CSM_booting

<matrix_bridge><Andrius Štikonas> muurkha: yes, but it is increasingly less and less available

<matrix_bridge><Andrius Štikonas> E.g. I have coreboot/uefi system where there is no CSM

<Googulator>CSM is really only a thing on AMD at this point

<Googulator>Intel no longer provides CSM-compatible processor and chipset support code to partners for CPUs released since January 2020

<Foxboron>This is accordance with the UEFI rollout plan from the UEFI Forum fwiw

<Googulator>they have also hinted at silicon changes that will make CSM insufficient for continued IBM PC/BIOS compatibility, something they apparently did for real in Meteor Lake, per pder's testing

<Googulator>& of course, Gate A20 was officially gone since Haswell, although it may have remained until Coffee Lake, just undocumented

<Googulator>ARM and RISC-V, of course, never had CSM to begin with

<Googulator>and Itanium is, well, dead

<Googulator>Are the maintainers of bootstrappable.org here?

<matrix_bridge><Andrius Štikonas> Repo is here https://git.savannah.gnu.org/cgit/guix/bootstrappable.git

<matrix_bridge><Andrius Štikonas> Seems to be coded in scheme

<Googulator>That's an interesting way to write web pages :)

<Googulator>anyway, last update was in 2021

<Googulator>I was going to ask for live-bootstrap to be linked

<Googulator>but that seems to be the least of the issues

<Googulator>back in November, when I first started working on bootstrapping, it took me quite a few false starts (e.g. trying to boot builder-hex0 in Hyper-V) before I stumbled upon LB

<matrix_bridge><Andrius Štikonas> Yeah, live-bootstrap needs more visibility...

<Googulator>The most recent advance reported on bootstrappable.org is Guix's reduced binary seed bootstrap (i.e. Mes as a bootstrap seed binary)

<Googulator>since then, Guix has almost achieved what LB has (minus kernel bootstrap and that pesky, non-reproducible static Guile)

<Googulator>but curiously enough, Guix provides virtually no information on how to _reproduce_ the full source bootstrap

<Googulator>BTW, looks like the latest builder-hex0 changes fixed live-bootstrap (baremetal image) running in a Gen 1 Hyper-V VM

<Googulator>building the mes->tcc transition as we speak

<Googulator>used to freeze in builder-hex0 stage1, and then in srcfs when stage1 was fixed

<Googulator>...but it freezes in make_fiwix_initrd

<Googulator>rickmasters: what would be needed in builder-hex0 to support something like "ls" or "find ."?

<rickmasters>Googulator: A lot that isn't there. There are no data structures for what is in a directory.

<rickmasters>Googulator: So getdirents would have to search the entire file system and would need to remove duplicate filenames which can currently exist.

<Googulator>I was thinking of a more naive implementation that just searches through the entire file descriptor set for names matching a prefix

<Googulator>given that we have a hard limit of just over 14000 anyway

<Googulator>but yeah, duplicates could be a problem

<rickmasters>Googulator, since last dup file wins, the current searches deal with that by just starting at the end.

<Googulator>how do we even get duplicates in the first place?

<Googulator>writing twice to the same file?

<rickmasters>yes, and since the current file system is just a bunch of blobs squished together it can't really expand files easily, so I just avoid that

<rickmasters>I've thought of other methods like moving a re-opened file to the end of the file system, and shifting all the others down.

<rickmasters>I've tried to keep the file system as simple as possible.

<rickmasters>The current design doesn't allow writing to more than one open file at a time and miraculously that doesn't happen,

<rickmasters>except for one place in tcc which I was able to easily patch around.

<Googulator>We could do something similar to FAT's handling of deleted files

<Googulator>since all filenames, as stored now, begin with a slash - just erase the slash when a file entry is no longer valid

<Googulator>doesn't free the space, but avoids duplicates

<Googulator>and makes unlink() possible

<rickmasters>It's all a balance between requirements and complexity. An argument can be made to defer doings stuff like unlink and ls until we have a real OS.

<rickmasters>s/OS/kernel

<Googulator>my goal with this is to get rid of fiwix_file_list.txt

<rickmasters>Once the code is easy enough to write (after building a good compiler) stuff can also be done in user land by just accessing the kernel memory directly.

<Googulator>right, make_fiwix_initrd could just parse the FS data structures

<rickmasters>See kexec-fiwix which finds /boot/fiwix.ext2 by directly searching the kernel memory file system entries.

<Googulator>speaking of which, what would be a future-proof way of doig https://github.com/fosslinux/live-bootstrap/blob/master/steps/lwext4-1.0.0-lb1/files/make_fiwix_initrd.c#L206 ?

<Googulator>0x7F8D was valid for the version of builder-hex0 included in the kernel-bootstrap subdirectory of LB, but it changes with each commit

<rickmasters>Oh, ugly. Forgot about that.

<Googulator>kexec-fiwix uses fopen, btw

<Googulator>oh, I see what you mean

<Googulator>the initrd

<rickmasters>So, luckily it looks like the code from make_fiwix_initrd you pointed to is informational only.

<rickmasters>I think I was using it to make sure I wasn't exceeding memory limits.

<rickmasters>If I wanted to rewrite that I could search the file table after opening the file and get the location that way.

<rickmasters>Or it could just be removed.

<rickmasters>Googulator: if unlink zero'd the filename and we pre-emptively unlink on opening files for write, then there wouldn't be duplicates.

IRC channel logs

2024-01-30.log