fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

#efi

1 post1 participant0 posts today

I setup #systemd-boot on my computer, but there were a couple of annoyances:

  • The #kernel isn't signed for whatever reason. I wired in sbctl sign to the install script, but that wasn't completely straightforward.

  • Since #Windows is installed in a separate #EFI (because Windows likes to fuck up the entire EFI partition sometimes) it couldn't "see" the Windows Boot Manager. I copied it to the other partition, but it will have to be manually updated whenever Microsoft changes it. Maybe that doesn't happen that often idk.

Side problem is that #Ubuntu's nvidia-lowlatency kernel isn't set up to reject unsigned modules, so it's a bit of a security hole, but also means that I don't have to figure out getting #DKMS to use the correct key. Right now I don't have a dependency on a DKMS-built driver. I used to use one for my dock and NVidia, but it seems that #NVidia doesn't need it now? and I don't use the video in my dock anymore because the #DisplayLink driver is annoying regardless of secure boot issues, because it doesn't work from power on. This isn't a problem with Linux, just DisplayLink in general.

Just finished the #RPi board support with #uboot #EFI in our beloved MTDA. First tried with the RPi EDK2 implementation, but that is far from being usable (who had the idea to convert a DT into ACPI tables???).

Even with Linux 6.12 many things do not work OOTB, like the RPi DTBOs cannot be used with the Kernels DT. Hence you manually need to port them - which is not trivial. #debian #linux #oss

github.com/siemens/mtda/pull/4

Well... the EDK2 attempt was a dead end. While it is advertised as the more "modern" solution and some distros already use it, it is definitely not suitable for more complex cases like MT...
GitHubfeat(rpi): switch to U-Boot as EFI provider by fmoessbauer · Pull Request #469 · siemens/mtdaBy fmoessbauer

Już na samym początku (w 2019) musiałem coś w tym kompku zrobić źle, działa więc się nie przejmuję, ale w sumie o co ta jazda ze specjalną partycją EFI i czary mary jakieś jak on z jakiegoś powodu uznaje, ok nie masz jej tak? Spoko. Jedziemy dalej…

Bo ja tak na prawdę to tę partycję mam tylko coś spaprałem i ona leży pusta chyba. No, a skoro działa, wiadomo… nie ruszać! :D

Die Forschungs- und Innovationspolitik der neuen Bundesregierung muss schlagkräftiger werden – zu diesem Fazit kommt die Expertenkommission #Forschung und #Innovation (#EFI) unter Leitung von Prof. Dr. Uwe Cantner, Wirtschaftswissenschaftler der #UniJena. Am heutigen Mittwoch, 26. Februar, übergaben die Kommissionsmitglieder ihr neues Jahresgutachten an Bundeskanzler Olaf Scholz.

➡️ uni-jena.de/300751/forschungs-

After jumping between distros my EFI partition is a bit of a mess, and as a result my BIOS boot menu is too. Some long gone distros are listed as well as some generic entries like “Linux”. Are there tools to help me clean up an EFI partition? I could just guess which files I can remove, but surely there’s a better option.. #EFI #UEFI

I have an Intel #N100 board from Chinese "brand" KingnovyPC. It used to work well, but now, when power is unplugged, it forgets date/time and also #EFI variables. So on power-up, it boots into the BIOS setup, and I have to boot from a rescue Linux USB stick to re-write the EFI vars to boot from NVMe again... until the next power down.

The CMOS battery is dead, which explains the date/time problem, but did they REALLY also store EFI vars in CMOS-RAM, or is my hypothesis wrong?

UEFI оказалась не такой уж и сложной технологией.

Оказывается, можно просто создать раздел FAT32 с типом ef, сделать его активным, создать там папку EFI, а в ней BOOT. И положить туда grubx64.efi переименовав его в bootx64.efi. И при перезагрузке прошивка EFI материнской платы сама найдёт этот раздел, залезет в папку EFI/BOOT и загрузит и запустит bootx64.efi. И появится командная строка GRUB2.

Если подложить в правильное место grub.cfg, то появится меню, а не командная строка.

Поскольку я использовал для экспериментов GRUB из ubuntu, то в нём был захардкожен путь /EFI/ubuntu. Соответственно, туда и пришлось класть grub.cfg и grubenv (для удобства).

Но это при условии, если в NVRAM переменные BOOT001, BOOT002 и т.д. отсутствуют или ведут к несуществующим или поломанным загрузчикам. UEFI в первую очередь пытается загрузить файлы загрузчики из этих переменных.

Можно ещё распаковать в EFI раздел rEFInd, который может загружать разные операционные системы в режиме EFI. А поскольку он основывается на GRUB2, тоже умеет напрямую грузить ядро linux.

#uefi#efi#grub2

You know what would be cool as a weekend project? A Linux Recovery Partition.

Shove in a basic desktop environment, tools to recover data, boot, and EFI partitions, a Bootloader Manager GUI, some backup/restore apps, and you're set.

How can I do that? I don't know, but I'm eager to use Debian with GNOME and everything stripped out to make it <1GB.

Почти на любой не особо древней материнской плате можно использовать NVMe-диск M.2 вставленный через PCI-адаптер (PCI x4) в какой-нибудь из нескольких PCI-слотов (желательно с четырьмя и более каналами).
В таком случае SATA-диски проигрывают по скорости в несколько раз, даже при наличии на материнской плате поддержки лишь древней второй версии #PCIe (PCIe v.2). На вполне конкретных примерах вместо 390 Мб/с наблюдается стабильные 1,7 Гб/с.

Загрузка системы на NVMe
Обычно, людей останавливает тот момент, что BIOS (точнее EFI) древних материнских платах не позволяет загружаться с NVMe-дисков, но это не является проблемой в случае таких систем как линуксы.
Т.е. сама по себе система (ОС) может располагаться на nvme-диске, но загрузчик системы с #initramfs и образом ядра при этом на совершенно другом диске или же вообще на вынимаемом носителе.
Для запуска системы нужен boot-раздел весьма скромный по размерам, хватит и 200-300 мегабайт. И располагаться таковой boot-раздел может хоть на flash'ке, хоть на SD-карточке или же быть разделом на SATA-диске.

Как работает загрузка ОС?
При включении питания #UEFI, оно же #EFI, читает записи в своей энергонезависимой памяти #NVRAM в поисках информации о том, какие EFI System Partition (ESP) на каких носителях следует использовать в каком порядке.
#ESP это обычный раздел (partition) с файловой системой FAT16 или FAT32, которую прекрасно понимает EFI-система и на ней смотрит файлы являющиеся загрузчиками сродни: #rEFInd, #GRUB или #systemd-boot
Так же, в качестве загрузчика может быть и специально собранный образ ядра ОС — например, т.н. EFI boot stub.

Или проще добавить поддержку #NVMe?
Иногда вполне реально научить комп грузиться с NVMe. Надо взять «Intel ME Tools» и снять дамп SPI Flash чипа на материнской плате, а в снятый образ EFI-системы добавить NVMe-драйвер (через «UEFI Tool»). После чего, уже пропатченный образ записывается обратно в SPI Flash чип на материнской плате.

Доводилось такое выполнять, используя «Flash Programming Tool» (fpt.exe) из пакета «Intel ME Tools» и это не из под Windows, а из под #FreeDOS. Создавая загрузочную флешку через dd и докидывая на неё один файл «fpt.exe».
Не сказать чтобы удобно, но дампить и шить из под Windows требует сперва установить и саму эту ОС и нужные драйвера от материнской платы вместе с Intel ME/AMT. И выходит, что в ряде случаев проще и быстрее лишние пару раз загрузиться с флешки.

В более поздних версиях «Intel ME Tools» для более новых материнских плат (чипсетов, PCH) появился вариант «Flash Programming Tool» и для линухов. Ненаглядный «flashrom» в ряде случаев бесполезен, может снять дамп лишь с одного из чипов, коих обычно две штуки. Т.е. вместо 12 Мб сделает дамп лишь 8 Мб, то же FPT во время работы показывает с какого SPI-чипа сколько снято или в него записано.

#nvme #nvmessd #linux #hardware #intel #IntelME #lang_ru @Russia
hub.hubzilla.deHubzilla.de

A brief history of Mac firmware – The Eclectic Light Company

Link
📌 Summary: 本文探討了蘋果電腦固件的演變,從早期的68K處理器和PowerPC架構,到近期的Intel和Apple Silicon M1家族。在這個過程中,蘋果採用了Open Firmware和EFI(統一可擴展固件介面),轉變為更安全的固件機制。特別是Apple Silicon Macs引入了新的啟動過程,設計上著重於建立一個無法被惡意攻擊的信任鏈,並支持從IPSW映像檔升級或降級固件,顯示出固件安全的重要性。

🎯 Key Points:
- 蘋果固件開始於Motorola 68K處理器,隨著PowerPC的引入轉向Open Firmware。
- Intel於1998年開發EFI,取代傳統BIOS,並且在2006年過渡到Unified EFI(UEFI)。
- 2015年以來,蘋果開始將EFI固件更新整合至系統更新中,以加強安全性。
- Apple T1和T2晶片引入了雙重固件體系,以提高安全性和功能性。
- 2020年蘋果推出M1晶片,重新設計固件,強調安全啟動流程和固件版本與macOS版本綁定。

🔖 Keywords: #固件 #安全性 #AppleSilicon #EFI #啟動過程
The Eclectic Light Company · A brief history of Mac firmwareFrom the Macintosh ROM of Classic days, to Open Firmware in Power Macs, and on to (U)EFI with Intel, and ending up with LLB and iBoot in Apple silicon Macs.