# FreeBSD just destroyed my UEFI



## Deleted member 63539 (Sep 8, 2020)

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.


----------



## VladiBG (Sep 8, 2020)

Do you need help to resolve this or not? What is the point of your post?


----------



## ekvz (Sep 8, 2020)

Maybe he is fishing for "Cool story, bro" type comments? In any case it took me a lot of willpower to not post this.


----------



## drhowarddrfine (Sep 8, 2020)

sysctl said:


> Bye.


It's about time. Praise your favorite deity.


----------



## sidetone (Sep 8, 2020)

Maybe the bootloader got overwritten. One would use the installer cd, to go to shell, then check out the files on the harddisk.


----------



## mickey (Sep 8, 2020)

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.


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?


----------



## Deleted member 63822 (Sep 11, 2020)

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
				




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.


----------



## DutchDaemon (Sep 11, 2020)

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.


----------



## ekvz (Sep 11, 2020)

gh_legacy said:


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



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.


----------



## Deleted member 63822 (Sep 11, 2020)

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.



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.



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


```
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
```


----------



## Deleted member 63822 (Sep 11, 2020)

Here is dmesg on MX Linux.


----------



## Deleted member 63822 (Sep 11, 2020)

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.


----------



## Zvoni (Sep 11, 2020)

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.


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 (Sep 11, 2020)

Most of the time it's user actions which destroy things. Not ?


----------



## Zvoni (Sep 11, 2020)

Alain De Vos said:


> Most of the time it's user actions which destroy things. Not ?


IT Layer 8 is not a myth!
I could tell you stories.......


----------



## Deleted member 63822 (Sep 11, 2020)

Alain De Vos said:


> Most of the time it's user actions which destroy things. Not ?


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.


----------



## ekvz (Sep 11, 2020)

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.


----------



## Deleted member 63822 (Sep 11, 2020)

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.



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.



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.


----------



## a6h (Sep 11, 2020)

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.


----------



## Mjölnir (Sep 11, 2020)

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.


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.


----------



## ekvz (Sep 11, 2020)

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.



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


----------



## ekvz (Sep 11, 2020)

gh_legacy said:


> You underestimate Linux's LVFS and fwupd too much.



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



No.



gh_legacy said:


> I'm sure you will find out many interesting things.



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.


----------



## Mjölnir (Sep 11, 2020)

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:

admin & user password
firmware update only by admin (ask for password & confirm update)
allow firmware downgrade


----------



## kpedersen (Sep 11, 2020)

ekvz said:


> It's true that i didn't know about `fwupd`. I'll give you that.



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!


----------



## Mjölnir (Sep 11, 2020)

I forgot to note that the OP gh_legacy now thinks that the thread title should be changed to *Linux just destroyed my UEFI.*


----------



## Deleted member 63822 (Sep 12, 2020)

Final answer:

FreeBSD didn't destroy my UEFI

Linux didn't arbitrary/automatically flash/update my BIOS without asking me

What really caused all of this is a corrupted GPT partition table, and this BIOS doesn't like that.

There is no way to completely clear the signature of a zpool.

I'm very careful.

I imported the zpool on the FreeBSD live memstick and zpool destroy it. Not works.

I used gpart destroy -F ada1. Not works.

I used gpt destroy da1 on Dragonfly. Not works.

Why I know it's not work? Open Gparted on Linux, and it's still show the old partition table of the previous FreeBSD installation even though I have overwritten this installation with both Dragonfly and OpenBSD. An orange colored zfs label still shown there.

dd if=/dev/zero of=/dev/sdb bs=1M count=256 not works. The corrupted GPT partition table and zfs label is still there.

So what worked?

Only dd if=/dev/zero of=/dev/sdb bs=10M. Yes, it's let it zero-fill the SSD completely that could cleared out the corrupted GPT partition table and zfs label!

I feared this ZFS too much! The current FreeBSD installation of mine is on UFS2. No ZFS, please.


----------



## kpedersen (Sep 13, 2020)

Remember after you do the:

`# dd if=/dev/zero of=/dev/sdb bs=1M count=256`

Also do a:

`# sync`

Just to be safe. Otherwise it might still be in a buffer by the time an installer analyses the disks.


----------



## Deleted member 63822 (Sep 13, 2020)

kpedersen said:


> Remember after you do the:
> 
> `# dd if=/dev/zero of=/dev/sdb bs=1M count=256`
> 
> ...


I did these dd with a live Linux usb so I restart immediately after dd was done. And no, only completely zero-fill the disk with dd could destroy zfs signature. It's a time consuming trial and error, so it took me many days to come up to the final answer.


----------



## Mjölnir (Sep 13, 2020)

Set `sysctl kern.geom.part.check_integrity=0` before doing `gpart destroy -F`?


----------



## Deleted member 63822 (Sep 13, 2020)

mjollnir said:


> Set `sysctl kern.geom.part.check_integrity=0` before doing `gpart destroy -F`?


Don't know. I have spent hours dd-ed the disks so I do not want to do that again. Maybe a tutorial in the Howto section about How to clear ZFS signature and the GPT partition table completely is needed.


----------



## Mjölnir (Sep 13, 2020)

To not let you access the partition table is clearly documented in RTFM dd(1): _BUGS_ section and RTFM geom(4): _DIAGNOSTICS_; i.e. `sysctl kern.geom.debugflags=0x10` (_allow foot-shooting_).



.


----------



## Deleted member 63822 (Sep 13, 2020)

mjollnir said:


> To not let you access the partition table is clearly documented in RTFM dd(1): _BUGS_ section and RTFM geom(4): _DIAGNOSTICS_; i.e. `sysctl kern.geom.debugflags=0x10` (_allow foot-shooting_).
> 
> 
> 
> .


No. I did the dd on Linux, a live Linux system on my usb stick. The commands run on FreeBSD are only `zpool destroy` and `gpart destroy -F`, both on the live FreeBSD memstick.


----------



## Zvoni (Sep 14, 2020)

In a (admittedly) sad way, i have to agree with the OP:
My two fileservers running FreeBSD12.1 are on UFS, no ZFS.
It just wasn't worth the hassle (at least for me).


----------



## Deleted member 63822 (Sep 14, 2020)

Zvoni said:


> In a (admittedly) sad way, i have to agree with the OP:
> My two *fileservers* running FreeBSD12.1 are on UFS, no ZFS.
> It just wasn't worth the hassle (at least for me).


Err, ZFS is not suitable for a test machine that usually be reinstalled with many OSes like mine but it's reasonable for a fileserver, though


----------



## ekvz (Sep 14, 2020)

Zvoni said:


> In a (admittedly) sad way, i have to agree with the OP:
> My two fileservers running FreeBSD12.1 are on UFS, no ZFS.
> It just wasn't worth the hassle (at least for me).



To be perfectly honest i personally haven't even tried ZFS. On a fileserver i might do it but on a desktop i just fail to see what problem those "advanced filesystems" would fix for me so i just stick to the beaten path of UFS2 on FreeBSD or Ext/XFS on Linux. Some day maybe i'll give it a chance but i am not in a hurry.


----------



## Zvoni (Sep 14, 2020)

gh_legacy said:


> Err, ZFS is not suitable for a test machine that usually be reinstalled with many OSes like mine but it's reasonable for a fileserver, though


True, but my "problem" was/is that i have to export a glustervolume via Samba (2x2 Disks on both Servers), and the hassle with ZFS just wasn't worth it (albeit i got it working in a first "incarnation").


----------



## Mjölnir (Sep 14, 2020)

ekvz said:


> To be perfectly honest i personally haven't even tried ZFS. On a fileserver i might do it but on a desktop i just fail to see what problem those "advanced filesystems" would fix for me so i just stick to the beaten path of UFS2 on FreeBSD or Ext/XFS on Linux. Some day maybe i'll give it a chance but i am not in a hurry.



instant snapshots (e.g. every 15 minutes with one of the many utilities in the ports tree)
boot envoronments
enhanced data integrity along the path from storage media to application
advanced management, espc. for jails & VMs


----------



## ekvz (Sep 14, 2020)

mjollnir said:


> instant snapshots (e.g. every 15 minutes with one of the many utilities in the ports tree)
> boot envoronments
> enhanced data integrity along the path from storage media to application
> advanced management, espc. for jails & VMs



I am not saying it doesn't provide any useful/interesting features. I am basically being lazy because there is nothing that really pressures me into using it. Also the memory requirement somewhat scares me.

I once tried Btrfs which somewhat is Linux's wannabe version of ZFS and it did little more than confuse me and also quickly got to a pretty hard to recover from state. Don't get me wrong, i very much expect ZFS to be of way higher quality but i am still somewhat reluctant since as long as i can remember traditional filesystems have just worked for me.


----------



## Mjölnir (Sep 14, 2020)

On an old laptop I was happy with UFS on gjournal(8) (article) & inserted the gsched(8) I/O scheduler (rc script). These two are independent from each other, you can have both or pick just one.  gjournal(8) requires setup during install, though.


----------



## ekvz (Sep 14, 2020)

mjollnir said:


> On an old laptop I was happy with UFS on gjournal(8) (article) & inserted the gsched(8) I/O scheduler (rc script). These two are independent from each other, you can have both or pick just one.  gjournal(8) requires setup during install, though.



I have to admit that FreeBSDs storage/disk concepts are still a bit of a mystery to me but some setup involving gjournal is very likely what i think i will end up using (unless it turns out soft updates really make journaling redundant at least - i've read this somewhere but it kind of seems to good to be true). I'll also probably setup some mirroring also but i am not really sure about the exact approach yet. I am somewhat drawn to ccd(4) though as it seems to be reasonably easy and also somewhat compatible with Linux's software RAID (not that i think i'll really need that but it's a nice touch).


----------



## Holger (Sep 14, 2020)

gh_legacy said:


> dd if=/dev/zero of=/dev/sdb bs=1M count=256 not works. The corrupted GPT partition table and zfs label is still there.
> 
> So what worked?
> 
> Only dd if=/dev/zero of=/dev/sdb bs=10M. Yes, it's let it zero-fill the SSD completely that could cleared out the corrupted GPT partition table and zfs label!



Note that a second copy of the GPT table is stored at the end of a hard disk image. This may be why just cleaning the first couple of sectors did not work.


----------



## Mjölnir (Sep 15, 2020)

Honestly I consider this thread _solved_ & gh_legacy should kindly ask the moderator to mark it so?


----------

