IRC channel logs
2024-02-19.log
back to list of logs
<stikonas>Googulator: also thanks for the advice yesterday, I was able to kick off baremetal bootstrap with preexisting kernel <Googulator>mid-kid: I'm having some trouble following your gentoo bootstrap <Googulator>(I'm porting it to bare metal within the live-bootstrap environment itself) <Googulator>specifically, where does the file wget-list-gentoo come from? <Googulator>TIL in 2024, LFS still checksums its sources using md5... 🤦 <fossy>Googulator: btw, were you thinking host ALL tarballs at archive.org, or only those that are known to possibly change? <fossy>at any rate, it is probably worthwhile to upload a full set of tarballs to archive.org <fossy>even if we aren't using them as a source <Googulator>For now, I only hosted the ones that are generated on the fly <Googulator>Mirroring the rest is probably a good idea, but I wouldn't redirect the actual downloads in that case <Googulator>except maybe for the Unicode text files, which are slow to download <stikonas>ok, so I think ./rootfs -b -qk kernel --external-sources is broken... <stikonas>so for now only non-external sources work with linux kernel <stikonas>it just creates a disk with tarballs and steps <Googulator>that's weird, it should generate the same thing as without --external-sources, except with more distfiles <fossy>did you have a non-empty target/ or smth? <Googulator>I guess we should check for a pre-existing target directory well in advance, rather than failing (or misbehaving) later in the process <stikonas>ok, I think I need to disable kernel bootstrap when when starting with linux kernel... <stikonas>probably fails to switch from 64-bit kernel to 32-bit kernel <stikonas>I think kexec is quite picky about arch sizes <fossy>you cannot kexec from 64 bit kernel to 32 bit kernel <fossy>back in the days before kernel bootstrap we used a 32bit linux kernel remember? <stikonas>but I don't think I can boot 32-bit kernel on UEFI without bootloader <stikonas>so for now I have manually set Chroot = True in bootstrap.cfg <stikonas>and for now I'll just do pure userspace bootstrap on baremetal <stikonas>and hopefully in the future we'll be able to advance UEFI bootstrap further <stikonas>other than this small issue, bootstrap with preexisting Linux kernel seems to be working fine... <stikonas>haven't finished yet, it's building guile now <stikonas>fossy: are those last programs in live-bootstrap, say diffutils or gawk supposed to be shared binaries? <oriansj>ideally we should have multiple mirrors, such that no single (or set of systems) going down would cause an issues. <oriansj>we could just list the mirrors and have a variable if set would cause the download script to pull from the mirror selected. <civodul>FWIW in Guix we’ve been working with Software Heritage, whose mission is to ensure long-term source code archival <civodul>perhaps that could be useful here as well? <pabs3>SWH don't store raw tarballs like you probably want <civodul>no, but that’s addressed by Disarchive <civodul>(i think i mentioned it here earlier (?)) <pabs3>IIRC its also computationally expensive to get git repos back out of SWH, so they don't offer it on-demand <civodul>they have to be “cooked”, which can take time <civodul>we’ve been discussing with them so they would “pre-cook” everything we might need <civodul>anyway, my point is that it’s worth getting in touch with them to address these issues <pabs3>ACTION is doing some work saving forges for them as an outside contractor <pabs3>no, I hadn't heard about the pre-cook stuff yet, that was interesting <pabs3>and indeed it is worth discussing with them further <oriansj`>yeah, source code preservation is a big problem <pabs3>(I'm part of ArchiveTeam too) <pabs3>and of course torrents, IPFS etc <Mikaku>I recommend to never send all these authentication commands inside a channel <nimaje>better yet to auth in a way that the other end can't know your secret <rickmasters>ok, I found a better way in my client so I don't have to do it manually. TIL <stikonas>yeah, I would also recommend using certificates as per nimaje's link <nimaje>and now I finally switched to certfp for libera too <oriansj>well; think of today as a good day to learn about password managers like keepassxc and bitwarden <oriansj>which generate secure passwords and can store entire password histories <stikonas>but just now I took an opportunity to also configure certfp for matrix_bridge <fossy>stikonas: hm, honestly didn't even cross my mind <fossy>should we make them static? i guess probably so for consistency <stikonas>well, static binaries are quite nice for bootstrapping <stikonas>you could run them from anywhere, no need to be properly chrooted... <stikonas>stuff like gcc does hardcode other paths... <fossy>mostly its either just --enable-static or LDFLAGS="-static" <stikonas>argh, I didn't setup interactive mode... <stikonas>so just got kernel panic at the end of bootstrap :D <rickmasters>Maybe I missed something; you have to setup interactive mode? <rickmasters>That's the first I've heard of that argument. I assumed it was automatic. <rickmasters>Googulator: So that explains why I didn't get bash prompt the other day. I didn't know it was an option. <stikonas>maybe for baremetal mode it should be default <stikonas>well, another thing is that for non-kernel bootstrap mode we do need to set Chroot = True <stikonas>it's not possible to do that from rootfs.py <stikonas>unless it's somehow possible to boot 32-bit efi file... <fossy>Googulator, stikonas: I noticed that the new bz2 file for diffutils-2.7 has a different umask for every file within it and an extra file RPI-configure in it compared to the upstream gz file. the size difference is ~50KB. personally i'd prefer that (like all the other xz files) they unpacked to the same directory structure... thoughts? <fossy>it's much easier to verify those tarballs are OK, imo, when they do unpack the same (even if the differences are not possibly nefarious) <stikonas>yeah, I would also think upstream file would be better <stikonas>at the very least repack should unpack to the same tar file <stikonas>(i.e. tar should be bit-by-bit identical <oriansj>unfortunately nefarious tarballs are a thing but yeah.