IRC channel logs
2024-08-11.log
back to list of logs
<mid-kid>So today I'm messing with the kernel+disk.img bootstrap <mid-kid>I ran `./rootfs.py -b --external-sources -qk bzImage` <mid-kid>And flashed the resulting disk.img to a drive <mid-kid>Then stuck GRUB and the kernel onto a flash drive, and ran `linux /bzImage root=/dev/nvme0n1p1 init=/init` <mid-kid>But it seems to crash with an "Attempted to kill init!" message right after the first line of the kaem.x86 file. <mid-kid>(right when the kaem-optional-seed process exits) <mid-kid>I'm not sure this makes a whole lot of sense to me? <mid-kid>right, kexecing from a 64-bit UEFI kernel into a 32-bit kernel isn't gonna work anyway <Rutherther>why does it have to be 32bit? and sorry for probably question with an obvious answer, I am new here and don't know anything about the toolings for bootstrappable kernel <mid-kid>the entire live-bootstrap chain is 32-bit right now <mid-kid>I was trying to avoid doing the chroot method from a livecd by using a custom-built kernel to paper over the fact that kiwix can't support my hardware <mid-kid>without realizing that a new kernel is built and booted partway during the bootstrap <mid-kid>other than that part, everything else is the same anyway if you're bootstrapping using a linux kernel :T <mid-kid>so I might as well stay with the chroot bootstrap <andydude>mid-kid: isn't there a way to exit 64 mode? <mid-kid>unlike protected mode and real mode you can't switch back from long mode to anything else <mid-kid>UEFI can run in protected (32bit) mode <mid-kid>so I assume this function is for that <mid-kid>that or it's used for some kind of virtualization <oriansj>well AMD64 has been out since 2002 and is superior to 32bit x86 in many ways (such as PC relative addressing, double the integer registers, etc) So there is probably a desire to abandon as much legacy as possible <oriansj>so expanding live-bootstrap to also support 64bit (and more architectures) seems like a good long term plan/investment <mihi>mid-kid, 64-bit grub-efi is able to load 32-bit Linux kernels (using the "internal" handover protocol, i.e. *not* via "linuxefi") and I've done it several times. To be honest, while I tried it on machines with CSM disabled, I never tried it on a machine that does not have a CSM at all, so maybe it is not working everywhere. <Rutherther>why are you people into bootstrappability? is it security, possibility to compile on systems without anything else, or is there something else I am missing? <andydude>Rutherther: I'm fascinated by the journey <andydude>I personally think the goal of bootstrapping is similar to the original goal of Paul Graham's Arc <andydude>"There must be some optimal path all the way up to a complete language" <andydude>Here, the language is GCC, and we have to figure out how to bootstrap it :P <andydude>I had a crazy idea at lunch today, something like a C compiler that compiles to sh/kaem and translates arith to "bc" calls, logic to "test" calls, data storage to environment variables, etc. <nimaje>could you at least use/build a not-terrible shell language for that? <mihi>Rutherther, I came to bootstrappability via Digital Preservation / Software Heritage. If everything except source code was lost, we'd need to bootstrap everything again. Also, trust issues (Trusting Trust Attack), identifying dependency cycles (generally making the work of sysadmins harder), and the debacle whether GNAT is actually free software when the there was only one piece of software that was able to <mihi>initially compile it, which was closed source. <mihi>Plus, I think it is a fascinating hobby.