Canoeboot 20241102 released! 4 new mainboards added. 100% free software BIOS replacement, GNU FSDG compliant

In fact, all of the Dell computers (laptops and desktops) can be flashed internally, without disassembly and without needing external equipment; the latter may be desirable, regardless.

See:

https://canoeboot.org/docs/install/latitude.html

https://canoeboot.org/docs/install/dell780.html

The guides document the installation procedure, for Dell Latitudes and Dell OptiPlexes respectively.

You need to set a special jumper on the OptiPlexes, but this is easy to do.

> We do not use vboot as it was declared non-free

Let's please have some nuance on that statement, is not that vboot-utils (vboot) is non-free, it uses some test data which is are blobs, others have no license and some others are plain non-free, that in itself doesn't render the whole package non-free, just the test data. AFAIK, GNU Boot uses vboot, just removing the data folder in their source.

So far, we have not had the time to untangle that so it has been removed while we find the time to remove that data, or have some answer upstream replacing that data with some better licensed one.

Please follow the thread at:

https://gitlab.trisquel.org/trisquel/package-helpers/-/issues/178

Your ignorance on this matter is astounding. If you'd actually read that announcement, you'd not say such a thing; your statement suggests that you skimmed the article for maybe 5 seconds. I'm actually annoyed that you even asked.

Skim this: Vboot is completely free software, but contains some non-free test data. I actually discovered this fact last year and deleted a number of them in the October 2023 releases of Canoeboot, **which was 1 YEAR AGO**.

A few more more were also discovered and deleted during 2024 when updating the coreboot revisions during that year. If you do spot any more, please let me know. I know the GNU people also have been raising a stink about this and contacting various projects that use vboot utilities.

Canoeboot is unaffected by this issue, rest assured. I delete the non-free data from vboot, and have done so since October 2023; I even contacted GNU about it and was ignored, until they discovered it themselves more recently :)

I also discovered a few more blobs recently, which both Canoe and GNU forgot to delete; I've informed GNU of the latter. See:

https://lists.gnu.org/archive/html/gnuboot-patches/2024-10/msg00029.html

They have now been addressing this, in recent patches as of November 2024. The vboot test data and the additional blobs linked above have all been *removed* in Canoeboot 20241102.

Now,

If you want to ask such a question in the future, here's how to answer it yourself:

Check the "nuke.list" files in cbmk, as described here:

https://canoeboot.org/docs/maintain/

Specifically: https://canoeboot.org/docs/maintain/#configprojectnuke.list

Vboot is a submodule of coreboot, so you wouldn't have a nuke.list for that, you would instead have it for the coreboot directory that it goes into. So for example in cbmk if you look at the file:

config/coreboot/default/nuke.list

As of the November 2024 release, you can see this entry:

3rdparty/vboot/tests/futility/data

Now, assuming you actually read this post, which I assume you didn't because you asked such a question in the first place which would suggest that you didn't read the original posts elsewhere about this topic, you will now know how to answer your own question next time, instead of annoying me with a question about an issue which I already reported myself 1 year ago.

The reason I'm irritated is because they actually had the gall to add in their bug tracker a TODO to contact Canoeboot about this issue, even though I reported it to *them* a year ago. So you ask such a question of me, because they rose a stink about it, but if I raise a stink about it, you wouldn't care, right?

I chose to respond to you, because unfortunately, this forum is full of people like yourself; many of them may even have only read what *you* wrote (after you didn't read what someone else wrote), and repeat what you said. It's like a game of chinese whispers and the resulting facts at the end are complete gibberish.

Think for yourself, and apply yourself, and don't waste my time again. Thank you. Now that I've gotten this out of my Canoe system, I can move on.

And if this insults you, that's good; use that anger and remember again my wisdom: think for yourself, apply yourself. Know your stuff. You know, actually read things and make your own mind up. Do your own research etc. Don't just repeat what you heard mindlessly like some annoying person on youtube comments sections.

I've made a note of this and will look into it at my next audit, regarding raw devices.

As for your second issue, and as mentioned on the very page which you link, it's possible to mitigate the SeaBIOS issue by disabling option ROM execution. You could also (if GRUB is already confirmed to work on your board) remove the SeaBIOS payload entirely, renaming the GRUB payload accordingly. For example, check:

./cbfstool canoeboot.rom print

If SeaBIOS is fallback/payload and grub is img/grub2, do this:

./cbfstool canoeboot.rom remove -n fallback/payload

./cbfstool canoeboot.rom extract -n img/grub2 -f grub.elf -m x86

./cbfstool canoeboot.rom add-payload -n fallback/payload -f grub.elf -c lzma

Then do this:

./cbfstool canoeboot.rom print

Confirm that GRUB is now fallback/payload; the size reported should be the same as what it was when it was img/grub2.

Now you can simply flash the result.

Also, instead of removing the SeaBIOS payload, you could extract it as above, to, say, seabios.elf on disk, and do:

./cbfstool canoeboot.rom add-payload -n seabios.elf -f seabios.elf -c lzma

The grub.cfg in Canoeboot will still show an option to boot SeaBIOS, if it's seabios.elf in flash.

I use the latter setup myself, on my own machine, though I use Libreboot on my personal machine, and not Canoeboot, but both projects use the same fundamental design.

EDIT:
Also mentioned on the link if you keep SeaBIOS, is how to disable the SeaBIOS menu and ensure that it only loads GRUB. This way, you never have the ability to load anything except the GRUB payload, from SeaBIOS. The reason it's there like that is because on some machines such as desktops, you would rely on executing the VGA ROM on a graphics card, though for Intel graphics on laptops it's not needed so perhaps you could try my advice above in making GRUB the first payload. On setups with graphics cards (desktop computers), SeaBIOS handles it and GRUB piggybacks off of the work that SeaBIOS did, otherwise there would need to be a separate coreboot config just for graphics cards, due to the way coreboot works; coreboot can handle one or the other, not both, but with coreboot doing native Intel graphics initialisation, and then loading SeaBIOS, SeaBIOS can handle graphics cards and therefore both scenarios are supported with the same coreboot configuration.

The reason SeaGRUB is the default even on laptops (where you would only have Intel graphics and therefore not need SeaBIOS for that) is because GRUB had some issues which I fixed in an earlier release, that before it was fixed caused some bricked machines. SeaBIOS tends to be more stable and break a lot less, so SeaGRUB is a sensible compromise that reduces the chance of bricks if I mess something up in a future testing release. So if I miss something on one of the machines and GRUB is unstable, SeaBIOS at least works.

Canoeboot/Libreboot are currently stable, where GRUB is concerned, but in the May 2024 releases I merged xHCI patches that actually caused memory corruption issues on some older boards if the OHCI driver was activated in GRUB. I mitigated it by not including xHCI support on such machines affected, which didn't need xHCI support in GRUB anyway, and the machines affected were actually Sandybridge machines which Canoeboot doesn't support anyway, so the machines in Canoeboot were probably fine - however, just to be safe, what I did was delete every ROM image for the May 2024 releases of both Libreboot and Canoeboot, and start a massive audit (audit 6 in libreboot and audit 2 in Canoeboot), which resulted then in the Libreboot 20240612 and Canoeboot 20240612 releases, which were both stable releases.

Yes, and then insert it as seabios.elf

In other words, inside the ROM images, you will have renamed SeaBIOS (fallback/payload) to seabios.elf and GRUB (img/grub2) to fallback/payload

As I've already mentioned, this is already written on the page. Quote:

https://canoeboot.org/docs/gnulinux/grub_hardening.html#disable-the-seabios-menu

You insert the bootorder file, so that SeaBIOS boots GRUB first, and then disable the SeaBIOS menu; by doing both things, SeaBIOS only loads GRUB and nothing else.

In that configuration, it will still execute option ROMs. On a laptop this shouldn't be an issue, since you would also write protect the flash and you're not inserting any there, but on a desktop you might consider disabling option ROM execution (also covered on that guide).

How to handle option ROMs, mentioned here:

https://canoeboot.org/docs/gnulinux/grub_hardening.html#seabios-option-roms

Disabling option ROMs is ill advised if you need to use a graphics card.