IRC channel logs

<stikonas>but if we start running out of RAM, I think the simplest solution might be to trim down kernel config

<oriansj>alMalsamo: I use libreboot but yeah, you will want the grub payload and luks version 1 for your /boot and then you can do anything you want for your / partition. However if you do a single partition, you'll be stuck with luks version 1 until grub improves its support for luks version 2

<alMalsamo>oriansj: Cool I had Libreboot on an X200 but I lost that machine :(

<alMalsamo>BUt with the ONLY payload of GNU GRUB does that provide a boot menu to choose between multiple internal SSDs, USB drive, optical drive?

<alMalsamo>And does this mean *no* GRUB on SSDs but GRUB only exists in NOR Flash?

<alMalsamo>And does this also mean I don't need a stupid EFI partition?

<plasma41>oriansj: Just a heads up, I got sick this week so I haven't gotten as far with the x86 stage0 work as I'd like. I think I'm past the worst of my symptoms and I'm looking forward to having a clear enough head to continue my work.

<oriansj>alMalsamo: you don't need EFI partition with a grub payload. I suggest also having grub installed on the SSDs to enable chainloading.

<oriansj>plasma41: get better first. The work can wait, your health comes first.

<plasma41>oriansj: thanks

<alMalsamo>oriansj: Hmm okay but what about boot menu to switch between hardware devices? I know SeaBIOS supports this but does GRUB payload provide this?

<alMalsamo>And what does chainloading provide?

<alMalsamo>oriansj: Oops I got disconnected, did you happen to answer my questions?

<stikonas>alMalsamo: there were no further answers

<oriansj>alMalsamo: if you prefer SeaBIOS, coreboot does support SeaBIOS so feel free to use that.

<alMalsamo>oriansj: Okay but does pure-GRUB payload offer boot menu to choose between physical boot devices? (eg 2 internal SSDs, USB drive, optical drive)

<alMalsamo>also what is the benefit of chainloading 2 GRUB installs, 1 in NOR flash and one on SSD?

<fossy>stikonas, sorry, i have had to deal with irl this last few days

<fossy>oriansj, stikonas: i don't really have an opinion either way on strict vs non-strict as a default. set -e does exist too but non-strict is the default on bash so i think that's why i haven't changed it in the past

<fossy>re: openssl 3, there was a dependencies reason, but i cannot explicitly recall the exact reason for it

<fossy>QEMU mode does seem to be fine, thankfully, the tarballs are less than a few hundred MB. i noticed that kexec error in my tests and that should be fixed in the next push

<oriansj>alMalsamo: well the advantage of chainloading grub is the firmware can be flashed and locked in read-only mode to prevent future tampering. (not everyone wants that but just FYI) and grub easily supports multiple boot options (it even has a prompt which can be used to manually override anything at boot time)

<stikonas[m]>fossy: OK, no problem. Openssl 1.1.1 would work.

<stikonas[m]>fossy: also, is it really better to put checksum variable into build script?

<stikonas[m]>Separate file might be easier to deal with...

<stikonas[m]>Not too sure about this yet, but it might be good to have a mode where checksum's are not checked but computed, so you run bootstrap and it created checksum file

<stikonas[m]>But that's probably easier if all checksum are in one file

<stikonas[m]>Then we wouldn't have to build one by one until the next error

<stikonas[m]>Also I don't like inline checksum variable for another reason:

<stikonas[m]>If we eventually have more arches

<stikonas[m]>That becomes trickier

<stikonas[m]>qemu-system without KVM is slow

<stikonas[m]>Although the whole checksumming on arches that you don't have might be tricky :(

IRC channel logs

2022-01-30.log