Test your BIOS and share your results on GitHub | Hacker News Reader

Test your BIOS and share your results on GitHub

github.com

157 pointsJulio-Guerra17 comments

Looks like a good initiative.

Would probably get more feedback if there was some simple scripts included which conducted and prepared a folder with all the logs for you.

Right now it looks like quite a bit of manual work, which could easily be cut down by providing a simple shell script. It doesn't even have to get you all the way (clone repo, get correct vendor+board, etc), but at least provide you with all the logfiles, consistently named. The readme could then guide you to what blanks you need to fill in yourself in the end.

Hopefully the currently half-baked state of this otherwise good initiative doesn't cause too many people who could have contributed to bail out.

Done. I released a tool helping to contribute. It tries to store the results according to the BIOS Information Table in the logs.

The new storage rule tries to be "deterministic".

So you want us to share our results? Then make it easy. Make a step by step guide. Include commands or scripts that we can execute. Show us what to upload where.

Take a common case scenario like with Ubuntu 14.04. Make screenshots of every step or copy every command you use in the terminal. Then you might get response.

Seems like a good idea, but the implementation is poor.

Please just write a tool that does the set of tests, displays results and optionally submits them.

Then distributions could package it, and people could run it.

The way it needs to be done right now implies too much effort and few people are going to bother.

That's a nice idea. Vaguely remember seeing something like this before, but since I don't know where that's not a problem. Might've been an Ubuntu initiative from a few years ago and was not necessarily only the firmware.

The introduction is missing that coreboot (https://www.coreboot.org/) exists.

Suggestion: Make it easier to contribute. I have no idea how to get fwts to give me the files shown for the example. Why not add a script that calls fwts the right way and formats the output as needed, and maybe uploads the result to somewhere?

I ran FWTS from its live image which does everything automatically, you don't have to do anything but wait for the results.

I'll had some explanations.

Can I make a suggestion? It looks like this is aimed at open-source users and it might be a better fit over on GitLab (https://gitlab.com/).

It's a great idea to create this repository of information, but putting it in GitHib's proprietary silo is a turnoff to some potential contributors. It isn't wrong to use GitHub, it's just better to make GitLab the default choice for FOSS (and especially crowd-sourced!) projects.

Either way good luck with it, I like the idea and as I'm already running Ubuntu I may try the PPA and see if I can generate some useful data to contribute.

> it's just better to make GitLab the default choice for FOSS (and especially crowd-sourced!) projects

Care to expand? I think many would disagree and even counter that putting things on GitLab is a turnoff to some potential contributors (it would be to me). Nothing against GitLab, but I think it's tough to make an argument for any single platform being the "default."

GitHub does have that popularity and mind-share going for it, so I can see why people might not care to leave and create a new account at GitLab. The primary concern is the license which could be identical at either platform so that's a non-issue.

The primary difference is that GitLab (referring to CE, the 'Community Edition') is completely portable and self-hostable. That means if things change later or the platform host gets a legal challenge or takedown request, you are free to say 'go pound sand' and take your data and platform elsewhere. You are not at the mercy of the platform provider.

For a classic example of a community effort where the rules were changed after a great many users altruistically gave of their time and effort see CDDB, also known as Gracenote[0]. And as I typed my original comment, this thread[1] was on the HN front page with some choice comments illustrating the difficulty of doing a 100% clean export of your data from GitHub.

Google has a great initiative, humorously called the 'Data Liberation Front'[2] which makes sure users can easily export all their data in a useful format if they want to take it elsewhere. I used it when I closed my Google accounts and I can report it works perfectly. I see no comparable effort by GitHub. Users like me check for this early and it's absence is always a red flag.

Hope that answers your question and if my assumption that you don't want to use GitLab because of the friction of creating yet another online account is incorrect please clarify what your real reason is.

[0]https://en.wikipedia.org/wiki/CDDB

[1]https://news.ycombinator.com/item?id=11054011

[2]https://en.wikipedia.org/wiki/Google_Data_Liberation_Front

Libreboot (https://libreboot.org/) is also interesting. The difference between them is that libreboot is a distribution of coreboot without any proprietary binary blobs, and an easier install path.

And that libreboot has no hardware support.

I released a tool helping to contribute. It tries to store the results according to the BIOS Information Table in the logs.

The new storage rule tries to be "deterministic".

Here is an easier to use bootable live image: https://wiki.ubuntu.com/FirmwareTestSuite/FirmwareTestSuiteL...

There is also https://lkml.org/lkml/2014/9/13/103

I updated the README to include your comments. Thanks for the feedback.

such an interesting thread, thanks for bringing this up!

At Packet, we've been working to support CoreOS and their Distributed Trusted Computing (https://tectonic.com/trusted-computing/) for our on-demand bare metal product. This relies on UEFI vs traditional BIOS. Reading up on this I've certainly learned a ton! A good background article I read was https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-...

For anyone who actually would like to know how modern machine boots, in a way which is practical and not just theoretical, this article is probably the best there is.

Definitely recommended for someone coming from the legacy BIOS boot background, expecting UEFI to be the same. (Hint: It isn't)

Basically while legacy booting has too many black boxes and black magic (from an end-user perspective) to be practical to work with, UEFI is actually inspectable and debuggable. If something fails, you can figure out why.

Best of all: Creating live USBs/CDs/whatever no longer requires special tools. Just copy the everything, including the EFI folder, and its automatically bootable.

UEFI is awesome.

Reply on news.ycombinator.com