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.
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.
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.
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?
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.
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.
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.
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.