Jesse Steele schreef op 06-08-2017 19:29:

My father told me as a kid, "I can't make enough rules." That's how I feel about which BIOS settings need changing on each 64 bit machine I encounter.

I would suggest that's bad parenting ;-).

I appreciated the GUI Ubuntu installer using a one-time password to change some BIOS settings. But, more BIOS settings changes from the GUI installer may needed now, in the future if possible, I guess. Many of my problems came up with "Windows 10 only" boot options, "Launch CSM" & Fastboot to be disabled, and whatever other need-to-be-disabled BIOS setting gets invented in 2018.

So basically you are saying that the changing and ... modernizing BIOS/UEFI landscape is causing the issues.

For you, I mean.

I do have one Abit AX78 from around 2009 that needs changing BIOS settings or else the kernel won't load.

I have had a load of other motherboards from that period and never had a problem.

Personally I don't like hash tags and I also don't think it is something to do with 64-bit.

It seems more like the maze that people are creating with UEFI etc.

We have problems today that didn't exist before. This goes for most things.

I think this article kinda says it:

"It’s never been harder to install Linux.

Don’t believe me? Just cast your mind back 10 years. Back then, it was just a matter of downloading an ISO, burning it to disk, pressing “next” a few times, and hoping you weren’t unlucky enough to have a Broadcom WiFi card. And if you didn’t fancy burning your own install disk, Canonical would send you one – for free. It was a wonderful time."

"Now, it’s less wonderful. Would-be Linux users have to contend with utterly awful hardware support, UEFI woes, and equipment designed to work with Windows, and Windows alone. If you want to break away from the yoke of Microsoft, you have to be a savvy hardware shopper."

But we already had 64-bit motherboards 10 years ago.

Ubuntu does have motherboard lists but they are woefully unupdated:

As well as being a hierarchical list that doesn't work all that well, and regular people don't have access to editing the wiki after it was closed down for reasons of spam.

What you really need is a single, editable list (by everyone) to which people can add their remarks but this is too technologically advanced for us ;-) (sorry to put it like this).

You really can't ask for everyone to start including that hashtag whenever and wherever they write something about their motherboard. You may think that's decentralized, but really it requires a concerted effort.

Back in the day wikis were community places, now they are publication portals.

Same thing happened to OpenSUSE btw.

Changing the GUI installer to make these changes creates work for the developers, I know.

But how can a GUI installer change any BIOS settings? I am puzzled.

My point here is that _community awareness_ of 64 bit BIOS settings/issues being slightly different from one manufacturer to another could show developers what the big issues are. Just by knowing on forums, "this is that same old issue, now with the INSERT-MAKE-MODEL..." in forums, developers could quickly see what BIOS settings the GUI installer might need to try to change, or something else.

You're not telling me software is now directly capable of changing BIOS settings, are you?

I'm happy to move on from this topic. My contribution is to consider if "#mb64" in any such forum issues could become unofficial SOP. No need to create extra work at this point.

That's a lot of extra work for everyone.

All you need is a single editable page. That is easy to find. There are hardware lists everywhere. But I couldn't really find anything. Even if you did create single pages for each motherboard, you would still need a single list, not the hierarchical system we have on the wiki.

And people need to be able to contribute easily. It's very simple you know.

The wiki is not a place that invites contribution.

(Neither is that of OpenSUSE these days).

Well enough.


Ubuntu-devel-discuss mailing list
Modify settings or unsubscribe at:

Reply via email to