Announcement

Collapse
No announcement yet.

AMD Releases BIOS Fix To Motherboard Partners For Booting Newer Linux Distributions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • thunder_burn
    replied
    I tried booting Manjaro and received the same errors as Michael.
    It works with the latest Manjaro 18.1 testing builds for me.

    Leave a comment:


  • oibaf
    replied
    Workaround is now in Ubuntu 19.04:
    Code:
    systemd (240-6ubuntu5.2) disco; urgency=medium
        [ Jeremy Soller ]
        * random-util: eat up bad RDRAND values seen on AMD CPUs.
          This fixes AMD Ryzen 3000 series failing to boot (LP: #1835809)

    Leave a comment:


  • monte84
    replied
    Originally posted by rbmorse View Post
    Debian Buster uses 241 and it's fine, too.
    Yes, Manjaro would not boot for Michael, same for me, they also appear to be on Systemd 242, not sure which sub version, Arch package shows 242-32. Tumbleweed being a rolling release, I was expecting the same problem, but did not have it. I tried booting Manjaro and received the same errors as Michael.

    Leave a comment:


  • rbmorse
    replied
    Debian Buster uses 241 and it's fine, too.

    Leave a comment:


  • monte84
    replied
    Got my Ryzen 7 3800X in today. Running BIOS 7106 for my Crosshair VI Hero X370 and no trouble booting into my Opensuse Tumbleweed install. Systemd version 242.

    Leave a comment:


  • rene
    replied
    Originally posted by pal666 View Post
    so what is precluding you from reading source comment?
    nothing, I'm just not interested in systemd and have other, important things to do

    Leave a comment:


  • pal666
    replied
    Originally posted by Danny3 View Post
    Systemd is the second most important part after the kernel from a distro building blocks and should try the make sure that it will not stop unless it's really something very very very important missing and only in that case shold stop the booting process.
    they didn't stop. their cpu operations were returning incorrect results which broke their program. how can you guard your program from some unknown cpu breakage? maybe some future bug will make cpu start substracting values instead of adding randomly, what can you do now when addition is working as intended?

    Leave a comment:


  • pal666
    replied
    Originally posted by rene View Post
    so, what is so important in systemd that it needs more then urandom early in the boot?
    so what is precluding you from reading source comment?

    Leave a comment:


  • Hugh
    replied
    Originally posted by Danny3 View Post

    Ok, it's good that they implemented a fallback, but they should learn something from this.
    Systemd is the second most important part after the kernel from a distro building blocks and should try the make sure that it will not stop unless it's really something very very very important missing and only in that case shold stop the booting process.
    I want lots of problems checked for. Even "impossible" ones, within reason. This was an impossible one.

    But coding a workaround for each impossible one multiplies the complexity of handling something that won't come up. And complexity is a breeding ground for bugs and for maintenance burden. I think that they probably made the right decision.

    Not everyone agrees with me, but I think that stopping when things are inconsistent rather than ignoring the problem is a good idea. Sometimes motoring through gets the right result, sometimes not (usually without the user knowing).

    So: what do you think they should learn? Why do you think that you know more than they do? Show some humility! It's not that suggestions are rude, but ones that don't reflect the context properly are not useful.

    Since systemd is so important now nothing else works if it doesn't work.
    They don't need a crystall ball, but they can check if the processor has some feature they want to use first and if the processor doesn't have it or it's broken, they could implement a fallback for it and put some message in the log file, but don't break the whole boot process because they want to use a nice to have feature and they can't.
    There is a well-defined test for the feature and systemd does test for it. Correctly. Exactly as you are desiring.

    As far as testing for broken features, that only make sense when particular bugs are known. Again, systemd now checks for this AMD bug. But that was only added when this bug (or a similar one) was discovered. Otherwise you certainly are demanding a crystal ball.
    "With great power comes great responsibility" - Spiderman
    I hope that th systemd developers understand now that they've made a very important piece for the Linux distro and they have a big responsibility to take care also about this unfortunate cases where is not directly their faul, but they can do something about it even for the future cases that might come.
    Please be specific here. Are you requesting that the handle all imaginable hardware bugs? Like 2 + 2 yielding 5?

    Leave a comment:


  • ozbird
    replied
    It's great that AMD has (presumably) fixed these issues quickly.

    However, the real test is how quickly board manufacturer release an updated BIOS with the fixes incorporated to users.

    Leave a comment:

Working...
X