IRC channel logs
2024-02-14.log
back to list of logs
<ekaitz>Googulator: so instead of just make, make boostrap2? <Guest000>Hello, I created an img with this command ./rootfs.py -b -a x86 --cores 4 on bare metal, then I flashed it on the USB driver and run from the bios, when does it go and the computer returns? it can be <Guest000>Hello, I created an img with this command ./rootfs.py -b -a x86 --cores 4 on bare metal, then I flashed it on the USB driver and run from the bios, when does it go and the computer returns? it can be <Guest36>Hello, I created an img with this command ./rootfs.py -b -a x86 --cores 4 on bare metal, then I flashed it on the USB driver and run from the bios, when does it go and the computer returns? it can be <efraim>so I don't forget for later, re early patch in live-bootstrap and possibly elsewhere, has anyone thought about using ed and an ed script instead of patch? IIRC there's a way to turn a diff/patch into a file you can pass to ed and that might help with ... something <Guest000>Hi, created an img with this command ./rootfs.py -b -a x86 --cores 4 on bare metal, then I flashed it on the USB driver and run from the bios, when does it go and the computer returns? it can be <Guest000>Hi, created an img with this command ./rootfs.py -b -a x86 --cores 4 on bare metal, then I f it on the USB driver and run from the bios, when does it go and the computer restart. what could it be? <matrix_bridge><Andrius Štikonas> In any case USB would still be very fresh and might be buggy <Guest000>Am i using the right command to make the img for bare metal? ./rootfs.py -b -a x86 --cores 4 <Guest000>1 step. ./rootfs.py -b -a x86 --cores 4 create img step 2. USB drive dd if=init.img of/dev/sda step 3. USB drive turn on in BIOS but half past restart all computer <matrix_bridge><Andrius Štikonas> So at the very least try to find out what happens just before restart <matrix_bridge><Andrius Štikonas> Now nobody can even see which step you reached before restart <matrix_bridge><Andrius Štikonas> (That said I personally haven't yet tried baremetal bootstrap on BIOS) <Guest000>Am i using the right command to make the img for bare metal? ./rootfs.py -b -a x86 --cores 4 <Guest60>HI how to create live-bootstrap ․իmg on bare metal <Guest60>HI, how to create live-bootstrap ․img on bare metal <mid-kid>Is it me or does the chroot bootstrap not work under WSL <mid-kid>I'm just messing around with the bootstrap, I know it's kinda worthless to do it on WSL but eh <rickmasters>mid-kid: That's not surprising. I doubt anyone is testing WSL. What happens? Does it get very far? <Googulator>yeah, bash will need to be rebuilt using its real build system (and/or with musl) to fix a mysterious globbing bug <Googulator>WSL2 with a custom kernel might work, as I believe it's dependent on the kernel used <Googulator>stikonas: how attached are we to the FSFLA deblob scripts for Linux? <Googulator>I'm hoping to replace it with a patch to just remove genuinely problematic drivers (that actually ship blobs inline with sources), since to me, the mere ability to load firmware doesn't look dangerous from a bootstrap trust perspective <mid-kid>rickmasters: It stops when trying to use a wildcard in the shell. I think there's probably something in the WSL kernel that mes-libc doesn't support <Googulator>most of what deblob-4.9 removes, even without --force, is features FSFLA considers "Free-baiting", rather than actual blobs <Googulator>so unless we need/want FSF compliance, it's doing more harm than good <matrix_bridge><Andrius Štikonas> Googulator: I think fossy was fine with removing it... <matrix_bridge><Andrius Štikonas> But yes, I guess these days all blobs live in linux-firmware tree <Googulator>the only instances of actual code blobs masquerading as source that I could find are in the vs6624 i2c driver (which looks like just a long list of register init values), and in the AppleTalk driver (the 2 blobs here are indeed firmware, which apparently once had source code, that has since then been lost to posterity) <Googulator>plus, there's a microcode update embedded in arch/powerpc/sysdev/micropatch.c, but we don't support POWER / PowerPC / PowerISA, and I doubt we ever want to <Googulator>4.9 additionally has some .ihex files in /firmware - they are all gone in 4.14, which I hope to upgrade to <Googulator>4.14 is the last version of Linux we can hope to build using gcc-4.0.4, and unlike 4.9, it's only gone EOL a few weeks ago <Googulator>close enough that we could just backport security-relevant patches from the still-supported 4.19 until we can move on to a newer gcc <Googulator>in 4.14, we can be sure that a patch removing those 2 drivers is enough to prevent blob hazard - unless someone involved actually wants all the political parts of linux-libre's deblob <Googulator>(e.g. the script tries, although fails, to replace the framebuffer penguin logo with a gnu / wildebeest because "GNU is more important than Linux") <Googulator>deblob-4.9 doesn't actually remove the vs6624 and PowerPC microcode patch code, so it's probably considered to be a false positive by the FSF <Googulator>there's also drivers/media/usb/dvb-usb/af9005-script.h - this one is removed; it does seem similar to vs6624, but at the same time, it's clearly a pregen file <Googulator>none of these are major functionality losses - I doubt DVB tuners are a usecase for live-bootstrap <rickmasters>fossy: I have an update on the m4 upgrade that broke the libtools package on Fiwix. <rickmasters>So m4 was producing a much smaller configure script for libtools, which didn't work. <rickmasters>I'm glad that was reverted because even though I was trying to figure it out <rickmasters>it was a hard problem and it was taking me a long time to make progress. <rickmasters>The failure occurs pretty far into the build and autotools has many opaque layers <rickmasters>and it's not clear exactly at what point m4 was doing the wrong thing. <rickmasters>Even though the upgrade was reverted and the problem was super tedious to resolve, <rickmasters>I decided that I wanted to get to the bottom of it, if only to learn autotools and m4 better. <rickmasters>By making detailed comparisons of m4 output between chroot and kernel bootstrap I was able to figure it out. <rickmasters>M4 can "divert" output to a temporary file and then insert those files back into the output. <rickmasters>m4-1.4.10 has a function for opening temporary files which is uses for both reading and writing. <rickmasters>It opens the file using append mode so writes will go to the end of the file. <rickmasters>The interesting part is that, on Linux, if you read a file that was opened in append mode it <rickmasters>actually starts reading from the start of the file. m4-1.4.10 depends on this. <rickmasters>But on Fiwix, these reads start at the end of the file. <rickmasters>I submitted an Issue and PR to Fiwix so it will behave the same way Linux does. <rickmasters>If/when that gets into live-bootstrap we will be able to update m4 on Fiwix if we need to in the future. <Googulator>oriansj: a quick heads up, linux-4.14.306.tar.xz triggers a bug in unxz <Googulator>if we do upgrade the kernel, it will need a stage0-posix commit with the fix included (or a temporary switch back to gz for the kernel sources)