FreeBSD just destroyed my UEFI

  • Thread starter Deleted member 63539
  • Start date
D

Deleted member 63539

Guest
It could be my UEFI firmware bug, but could be FreeBSD's, too. The only two OSes that caused this problem for me are OpenIndiana and FreeBSD. There is no Linux distro has such problem. I could say it's because Linux's support for UEFI is much better, or to be more correctly Linux's support for my UEFI firmware is much better.

Problem description: Just install FreeBSD 11.4 RELEASE from the memstick image, reboot into the newly installed system. Doing freebsd-update fetch && freebsd-update install, reboot, then stuck with a black screen, can't do anything, can't enter Setup, can't press F11 to choose which UEFI OS to load, nothing, the only thing possible to press reset but will be encountered by this black screen again, and the power button to power off.

How to resolve: detach the SSD disk reserved for FreeBSD from the system, and it will boot just fine.

How to restore the disk: attach this SSD via a USB port on a running Linux system, then launch Gparted, clear everything, create a new msdos partition table and create a new gpt partition table. Without creating a new msdos partition table, the old gpt partition table is still there.

Don't ask me to try anything. I will not refill this SSD with FreeBSD again at least in the near future. Maybe another Linux distro, but no BSDs. Bye.
 
Maybe he is fishing for "Cool story, bro" type comments? In any case it took me a lot of willpower to not post this.
 
Maybe the bootloader got overwritten. One would use the installer cd, to go to shell, then check out the files on the harddisk.
 
sidetone said:
Maybe the bootloader got overwritten. One would use the installer cd, to go to shell, then check out the files on the harddisk.
Click to expand...
Or maybe it did not update the bootloader and now it's trying to boot 12.x with an 11.4 boot loader? Does freebsd-update(8) even touch the bootloader? Especially the one on the EFI system partition? I'd certainly hope it doesn't. But then again, why install 11.4 in the first place?
 
forums.freebsd.org

FreeBSD just destroyed my UEFI

It could be my UEFI firmware bug, but could be FreeBSD's, too. The only two OSes that caused this problem for me are OpenIndiana and FreeBSD. There is no Linux distro has such problem. I could say it's because Linux's support for UEFI is much better, or to be more correctly Linux's support for...
forums.freebsd.org forums.freebsd.org

More information: Linux automatically updated the firmware of my hardware without even asking me, my SSD and even my BIOS, too. The old BIOS worked fine with FreeBSD, but the new one doesn't. The fact is the problem described on the thread above is applied for any other BSDs, Dragonfly, OpenBSD, NetBSD, all of them affected, not only FreeBSD. It's a buggy BIOS version that only Linux could work fine with it.

How to get FreeBSD/Dragonfly/OpenBSD/NetBSD boot: simple, just detach the SSD from the system, boot once time without this SSD attached, poweroff, reattach the SSD, then this time you could see the BSD boot loader. You have to redo this procedure every time there is a system upgrade, e.g: freebsd-update, OpenBSD's syspatch,... and it's annoying.

Disclaimer: I'm not sure if it's MX Linux doing this because I used a bunch of Linuxes on my system and I can't know which did all of this. This system now become BSD hatred and I think it will be Linux-only until it EOL. I'm a noob so downgrade the BIOS is too risky for me to even try.

p/s: to be more clear, it's not about automatically load the updated firmware at boot but indeed flashing the updated firmware into the device, it's too difficult for a noob like me to roll it back.

Another disclaimer: Don't believe this post as is and use this to judge, I'm not even sure about all of this. I'm just a noob after all and my observation could be wrong.

Update: I checked for the firmware version using this tutorial: https://wiki.archlinux.org/index.php/Fwupd#Usage As I have never updated my firmware since I bought this machine, the updated version displayed means (at least I think so) that they were automatically updated by Linux. Or it could BSD that updated it. But I think it's very unlikely, I'm more or less familiar with BSD's boot message and I didn't found anything fishy.
 
Right; I'll allow this to continue for a bit, but if this evolves into 'never FreeBSD again, bye' without any intent to learn or try things, it gets closed again.
 
gh_legacy said:
forums.freebsd.org

FreeBSD just destroyed my UEFI

It could be my UEFI firmware bug, but could be FreeBSD's, too. The only two OSes that caused this problem for me are OpenIndiana and FreeBSD. There is no Linux distro has such problem. I could say it's because Linux's support for UEFI is much better, or to be more correctly Linux's support for...
forums.freebsd.org forums.freebsd.org
Linux automatically updated the firmware of my hardware without even asking me, my SSD and even my BIOS, too.
Click to expand...

I happen to think it's very, very unlikely any OS would randomly flash literally any kind of hardware on it's own. It's often not all that easy to determine the appropriate images even for a human. Automating this would be downright suicidal and no sane person would even attempt to (who seriously wants to risk having to deal with an angry mob wielding bricked hardware?). Out of interest what kind of device are we talking about here (i.e. what board does the supposedly auto-flashed BIOS belong to)? Not that i seriously expect this to change my opinion but i figure maybe (just a very tiny, tiny maybe) there could be some edge case where automatic flashing wouldn't be such a 1000% mental idea.
 
ekvz said:
I happen to think it's very, very unlikely any OS would randomly flash literally any kind of hardware on it's own.
Click to expand...

I think so, too. So I'm very confused now. The Linux developers (distro specific, not kernel developers) are very good persons. I used to ask for help on both the MX Linux forum and SparkyLinux forum and they both replied me and I got the problem solved very soon. I spent hours searching on the internet about MX Linux and found nothing fishy about the way they handle firmware update. They have a big linux-firmware package (about 124 MB) but it's normal for other Linuxes, too. These firmware are loaded on boot, not flashed to the device. The fact is they even don't have fwupd package installed by default. It's me installed this package to check for the firmware version on my system. They don't have any fwupd service, too.

ekvz said:
It's often not all that easy to determine the appropriate images even for a human.
Click to expand...

Then you underestimate Linux's fwupd and lvfs a lot. This is the result of fwupdmgr get-devices on my system:

Code: 
MS-7817 System Firmware
  DeviceId:             1d70a31dd3ff0941761550a38436fc990c6c3ff0
  Guid:                 7039436b-6acf-433b-86a1-368ec2ef7e1f
  Plugin:               uefi
  Flags:                internal|require-ac|registered|needs-reboot
  Vendor:               MSI
  Version:              0.0.36
  VersionLowest:        0.0.36
  VersionFormat:        triplet
  Icon:                 computer
  Created:              2020-09-11
  UpdateError:          /sys/firmware/efi/efivars was not mounted

TEAM T253LE120G
  DeviceId:             0a8c36d4c09c803cd6b5861e443fb7a41a20cbe6
  Guid:                 e8c3f0e6-3b0a-50fa-8056-b4ddbb4979ff
  Guid:                 33246eb6-6439-56a6-81c4-1d7d8e9ee99e
  Guid:                 e8033cca-8942-5f40-ae28-1b0e100533fa
  Summary:              ATA Drive
  Plugin:               ata
  Flags:                internal|updatable|require-ac|registered|needs-reboot
  Version:              SBFM11.2
  VersionFormat:        plain
  Icon:                 drive-harddisk
  Created:              2020-09-11
 
Here is dmesg on MX Linux.
 

Attachments

  • dmesg.txt
    56.4 KB · Views: 105
Don't believe me, just treat me as a stupid troll. I want to know exactly what happened, too. Let's test it yourselves on a system that has firmware not updated and check if any of these OSes automatically updated the firmware or not. Recently I have only used these OSes on this test machine:

BSDs (Free/Open/Dragonfly/Net, all of them, but they are very unlikely to be faulty).
SparkyLinux https://sparkylinux.org/
MX Linux https://mxlinux.org/
OpenIndiana Hipster https://www.openindiana.org/

These distros only used under Bhyve or VirtualBox:

Fatdog64 https://distrowatch.com/table.php?distribution=fatdog
Emmabuntus https://distrowatch.com/table.php?distribution=emmabuntus

Yeah, a huge list. But let's focus on the Linuxes, especially MX Linux, the most recent Linux on my system. I'm typing on it now.
 
ekvz said:
I happen to think it's very, very unlikely any OS would randomly flash literally any kind of hardware on it's own. It's often not all that easy to determine the appropriate images even for a human. Automating this would be downright suicidal and no sane person would even attempt to (who seriously wants to risk having to deal with an angry mob wielding bricked hardware?). Out of interest what kind of device are we talking about here (i.e. what board does the supposedly auto-flashed BIOS belong to)? Not that i seriously expect this to change my opinion but i figure maybe (just a very tiny, tiny maybe) there could be some edge case where automatic flashing wouldn't be such a 1000% mental idea.
Click to expand...
Yeah. Right..... like the automatic Windows10-Upgrade-Rollout in our company, which tried to install a BIOS-Firmware-Upgrade for the Fujitsu-Batteries in our Fujitsu-Laptops.
Saving grace was, that we're behind a strict firewall/proxy-server disallowing connection to download the firmware.

Whoever thought it's a good idea to make BIOS-updates from within Windows (or any OS) should be quartered, tarred, feathered and used as fertilizer.....
 
Alain De Vos said:
Most of the time it's user actions which destroy things. Not ?
Click to expand...
No, this time not. I'm sure 100% that I didn't did anything abnormally. I never think I'm a hacker and have never ever think about firmware upgrade. I used to do this on Windows many years ago, for my DVD-RW drive, and all of my discs failed to burn, finally have to replace it with another drive, never want to try this again.
 
I very much doubt any OS would ship ROM images for some random BIOS. I looked up MS-7817 and it's not even a specific board but a whole family. There would be gigabytes and gigabytes of images in those distributions for hardware that might be impossible to tell apart from the viewpoint of the OS. Concerning the firmware packages of various distributions: I have yet to see one that ships anything (specially Debian based) that would be permanently flashed (as in survives a reboot). Same goes for the CPU microcodes supplied by the systems. All of those are loaded at every boot for a reason. That reason being that they won't be stored permanently.

I figure you might have tried some weird OSes but i still don't buy any of them shipping and automatically flashing a BIOS ROM without some hard evidence. A list of random (mostly Debian based?) distributions doesn't cut it for such a bold claim.
 
ekvz said:
I figure you might have tried some weird OSes but i still don't buy any of them shipping and automatically flashing a BIOS ROM without any hard evidence. A list of random (mostly Debian based?) distributions doesn't cut it for such a bold claim.
Click to expand...

I know this claim is serious so I added many disclaimers. You could read my post again. I didn't accuse any OS for responsibility, just trying to figure out what exactly happened.

ekvz said:
I very much doubt any OS would ship ROM images for some random BIOS. I looked up MS-7817 and it's not even a specific board but a whole family. There would be gigabytes and gigabytes of images in those distributions for hardware that might be impossible to tell apart from the viewpoint of the OS. Concerning the firmware packages of various distributions: I have yet to see one that ships anything (specially Debian based) that would be permanently flashed (as in survives a reboot). Same goes for the CPI microcodes supplied by the systems. All of those are loaded at every boot for a reason. That reason being that they won't be stored permanently.
Click to expand...

Then again you didn't even have a look at my reply. You underestimate Linux's LVFS and fwupd too much. Doing a quick research on Google would give you many more information. Please, download at least MX Linux, and on the terminal of it try apt search fwup and do your own research. I'm sure you will find out many interesting things.
 
vigole said:
Some systems support UEFI capsule updates. Some OS like Ubuntu >=16.04 notify and flash(?) BIOS. There's some explanations on Flashing a Dell BIOS in a Linux Only Environment. The whole practice is creepy IMHO.
Click to expand...
Wow, didn't know that such services exist! Well, you can identify devices by their UUID or such & if you have a certified, secure source for a 100% certified firmware for exactly that model you identified, why not update it? We're not in the 80ies. Of course, such action should be clearly announced & optionally confirmed. The latter beeing omitted only in remotely administered environments.
 
  • Like
Reactions: a6h
mjollnir said:
Wow, didn't know that such services exist! Well, you can identify devices by their UUID or such & if you have a certified, secure source for a 100% certified firmware for exactly that model you identified, why not update it? We're not in the 80ies. Of course, such action should be clearly announced & optionally confirmed. The latter beeing omitted only in remotely administered environments.
Click to expand...

Because it might be hard to undo and newer doesn't always equal better. I am sitting next to a desktop which BIOS i updated not to long ago. It's certainly not running the latest version though and most likely never will (it would mean loss of features and gain me nothing).
 
gh_legacy said:
You underestimate Linux's LVFS and fwupd too much.
Click to expand...

It's true that i didn't know about fwupd. I'll give you that. Now you just need to point at a distribution that installs it by default in fully automatic mode.

gh_legacy said:
Please, download at least MX Linux
Click to expand...

No.

gh_legacy said:
I'm sure you will find out many interesting things.
Click to expand...

I allready did. It's very interesting to me that doing minimal installs and setting up the system on my own will make sure i'll never come into contact with something like fwupd. That's all what's relevant for me to know.
 
I'm not shure if all this can be circumvented by AMT (remote administration on BIOS level), which I have switched off: besides AMT on/off, the UEFI on my machine has 3 other switches concerning this:
  1. admin & user password
  2. firmware update only by admin (ask for password & confirm update)
  3. allow firmware downgrade
 
ekvz said:
It's true that i didn't know about fwupd. I'll give you that.
Click to expand...

I notice that FreeBSD has a more relaxed view on firmware, so we rarely need stuff like this. Worst case, we can just grab it from a package or ports.

For OpenBSD that is very strict on firmware they have a cleaner tool that doesn't need to hook into systemd or whatever Linux uses these days (https://man.openbsd.org/fw_update)

Though personally I find it more deterministic to just grab it from the http server. For example their one for 6.7 here: http://firmware.openbsd.org/firmware/6.7. So clean and simple! It almost makes you wonder why firmware is ever an issue for users!
 
You must log in or register to reply here.
Back
Top