Continued thread
If it helps anyone else the line needed to be:
```
options root=ZFS=rpool/ROOT/ubuntu_wg574t <rest of line>
```
That being the name outputted when running: `zfs list /`
#systemdboot
0 posts0 participants0 posts today
Now that I have #uboot, #systemdboot and #nixos running on my phone, no one will be able to stop me, mwuahahah
#weeknotes
#weeknotes
Nice, it looks like there's going to be a #SecureBoot-signed version of #systemdboot in #DebianTrixie.
https://packages.debian.org/trixie/systemd-boot-efi-amd64-signed
Про полнодисковое шифрование #FDE средствами #Luks
На ровном месте проявилась проблема, что идентификаторы разделов (partitions) теряются в определённых обстоятельствах. Потому система не может загрузиться, из-за чего в опции
Т.е. идентификатор шифрованного LUKS-раздела затирается в каких-то обстоятельствах и отдельных случаях, тем самым является совершенно ненадёжным способом указания на раздел диска.
Например, это затирание было замечено после того как выполнялось выставление флагов allow-discards, no_read_workqueue и no_write_workqueue через:
Соответственно, для `systemd-boot` загрузчика в файле /boot/loader/etries/your-system-100.500.conf приходится указывать нечто сродни:
Где:
Тоже самое касается и /etc/cryptsetup.initramfs, если таковой используется.
Почему #systemd-boot?
Использование #GRUB весьма неразумно при полнодисковом шифровании, так же использовать GRUB затруднительно, когда при старте надо открывать несколько шифрованных разделов.
Например, один из разделов на диске может быть swap, в который сохраняется система при hibernate. Да swap может быть и файлом на основном разделе, но далеко не всех такое устраивает и не все файловые системы это поддерживают.
#lang_ru #linux #LUKS
На ровном месте проявилась проблема, что идентификаторы разделов (partitions) теряются в определённых обстоятельствах. Потому система не может загрузиться, из-за чего в опции
rd.luks.data приходится использовать /dev/disk/by-id/... вместо UUID'а раздела на диске.Т.е. идентификатор шифрованного LUKS-раздела затирается в каких-то обстоятельствах и отдельных случаях, тем самым является совершенно ненадёжным способом указания на раздел диска.
Например, это затирание было замечено после того как выполнялось выставление флагов allow-discards, no_read_workqueue и no_write_workqueue через:
cryptsetup open --type luks2 --persistent --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue ...Соответственно, для `systemd-boot` загрузчика в файле /boot/loader/etries/your-system-100.500.conf приходится указывать нечто сродни:
options rd.luks.data=7f2df3a2-3c68-492e-bbd6-1ccf956379c0=/dev/disk/by-id/nvme-VENDOR_MODEL_SERIAL_ID_-partN
options rd.luks.name=7f2df3a2-3c68-492e-bbd6-1ccf956379c0=crypto_dev_name
... или ...
options rd.luks.data=2b507209-fcf1-4aae-a55a-1ba4e908cc8b=/dev/disk/by-id/ata-VENDOR_MODEL_SERIAL_ID_-partNГде:
- partN — это part1 или part2... part3 и т.д. номер разделов.
- Используемые UUID'ы это из Luks-заголовка, т.е видимые через
cryptsetup luksDumpи отсутствующие в выдаче:lsblk -f - Идентификаторы разделов конкретного диска ...-VENDOR_MODEL_SERIAL_ID_-partN можно наблюдать через:
ls /dev/disk/by-id/
Тоже самое касается и /etc/cryptsetup.initramfs, если таковой используется.
Почему #systemd-boot?
Использование #GRUB весьма неразумно при полнодисковом шифровании, так же использовать GRUB затруднительно, когда при старте надо открывать несколько шифрованных разделов.
Например, один из разделов на диске может быть swap, в который сохраняется система при hibernate. Да swap может быть и файлом на основном разделе, но далеко не всех такое устраивает и не все файловые системы это поддерживают.
#lang_ru #linux #LUKS
hub.hubzilla.deHubzilla.de
Почти на любой не особо древней материнской плате можно использовать 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
В таком случае 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
Про #GRUB можно позабыть уже несколько лет как — явно находится под чьим-то влиянием и до сих пор отказывается реализовать поддержку #LUKS 2-й версии, в части использования #Argon2 / #Argon2id.
Важно это потому, что в мире полно ферм для майнинга криптовалют, так или иначе арестованных органами общественного правопорядка. Это изначально специализированные #ASIC для перебора значений hash-функций. В результате, стало возможным взламывать грубой силой почти все варианты дискового шифрования, если для хранения пароля используются обычные #PBKDF2 / #PBKDF, не адаптированные под противодействие крипто-майнинговым фермам. Примером, нормальной современной #PBKDF является тот же #Argon2 и его вариации.
Альтернатива в том, что позволяет тот же #systemd-boot. Например, для полнодискового шифрование через LUKS берётся SSD/NVMe разбитый через #GPT с выделением раздела EFI System Partition, на котором размещаются образы #initrd / #initramfs и бинарники загрузчика systemd-boot являющиеся EFI-приложением.
Всё содержимое EFI System Partition может проверяться Secure Boot'ом — быть заверены своим собственным сертификатом в дереве. Не только бинарники, но и текстовые *.conf файлы в /boot/loader/entries/ описывающие каждый вариант загрузки. Поскольку они содержат такие вещи как:
Т.е. файлы *.conf могут содержать всякие опции/параметры ядра, отвечающие за безопасность работы системы. Например, раздачей таких рекомендаций недавно развлекался #ФСТЭК (вот оригинал официальной публикации).
Про различия в вариантах #Argon2, почему собственно RFC 9106 рекомендует использовать #Argon2id
#linux #crypto #lang_ru
Важно это потому, что в мире полно ферм для майнинга криптовалют, так или иначе арестованных органами общественного правопорядка. Это изначально специализированные #ASIC для перебора значений hash-функций. В результате, стало возможным взламывать грубой силой почти все варианты дискового шифрования, если для хранения пароля используются обычные #PBKDF2 / #PBKDF, не адаптированные под противодействие крипто-майнинговым фермам. Примером, нормальной современной #PBKDF является тот же #Argon2 и его вариации.
Альтернатива в том, что позволяет тот же #systemd-boot. Например, для полнодискового шифрование через LUKS берётся SSD/NVMe разбитый через #GPT с выделением раздела EFI System Partition, на котором размещаются образы #initrd / #initramfs и бинарники загрузчика systemd-boot являющиеся EFI-приложением.
Всё содержимое EFI System Partition может проверяться Secure Boot'ом — быть заверены своим собственным сертификатом в дереве. Не только бинарники, но и текстовые *.conf файлы в /boot/loader/entries/ описывающие каждый вариант загрузки. Поскольку они содержат такие вещи как:
title ... — как зовётся в меню загрузочном
linux /vmlinuz-6.6-x86_64 — какое ядро ОС использовать
initrd /intel-ucode.img — какой микрокод процессора грузить
initrd /initramfs-6.6-x86_64.img — сам загрузочный образ
...
options quiet — могут быть и в одну строчку все сразу
options splash
options rd.udev.log_level=3
options systemd.show_status=auto
options sysrq_always_enabled=1
options intel_iommu=on
options iommu=pt
...Т.е. файлы *.conf могут содержать всякие опции/параметры ядра, отвечающие за безопасность работы системы. Например, раздачей таких рекомендаций недавно развлекался #ФСТЭК (вот оригинал официальной публикации).
Про различия в вариантах #Argon2, почему собственно RFC 9106 рекомендует использовать #Argon2id
- #Argon2d maximizes resistance to GPU cracking attacks. It accesses the memory array in a password dependent order, which reduces the possibility of time–memory trade-off (TMTO) attacks, but introduces possible side-channel attacks.
- #Argon2i is optimized to resist side-channel attacks. It accesses the memory array in a password independent order.
- #Argon2id is a hybrid version. It follows the #Argon2i approach for the first half pass over memory and the #Argon2d approach for subsequent passes.
#linux #crypto #lang_ru
hub.hubzilla.deHubzilla.de
Пока #KDE создаёт свой дистрибутив #linux, что делают гаврики из #GNOME ? Прожигают подушку безопасности верстая бюджет с дефицитом! :)
И отказываются всего лишь от таких вещей как пара директоров и затраты на транспортировку представителей своего сообщества, управляющего совета и персонала GNOME Foundation на всякие мероприятия. Однако, оставляют расходы на программы оплачиваемых стажировок Outreachy ориентированной на такие социальные группы, которые оказывается слабо представлены в сфере разработки open source (free'шного ПО).
А в #KDE просто задолбались с тем, что присутствуют в подавляющем числе дистрибутивов #linux лишь в сильно пропатченом и потому кривом виде (из-за убогости ментейнеров этих дистрибов).
Потому KDE и решили делать свой дистриб, на базе #ArchLinux, в котором #KDE давным давно присутствует прямо в нативном, неизменённом виде.
Причём в KDE весьма разумно подходят к вопросу:
У самого несколько лет именно так и есть — обновления с автоматическими через #TimeShift снапшотами файловой системы (средствами btrfs) при накатывании обновлений или установке софта.
И полнодисковое шифрование LUKS, возможности которого нормально поддерживает лишь systemd-boot.
Т.е. пока #GNOME прожирает средства на всякую откровенную херню, в то же самое время #KDE заняты весьма годными делами. И лепят вполне современный дистрибутив, закладывая в него более чем разумные практики и вообще, и в том числе, ещё и с дистрибьюцией софта через #flatpak.
#crypto #lang_ru
И отказываются всего лишь от таких вещей как пара директоров и затраты на транспортировку представителей своего сообщества, управляющего совета и персонала GNOME Foundation на всякие мероприятия. Однако, оставляют расходы на программы оплачиваемых стажировок Outreachy ориентированной на такие социальные группы, которые оказывается слабо представлены в сфере разработки open source (free'шного ПО).
А в #KDE просто задолбались с тем, что присутствуют в подавляющем числе дистрибутивов #linux лишь в сильно пропатченом и потому кривом виде (из-за убогости ментейнеров этих дистрибов).
Потому KDE и решили делать свой дистриб, на базе #ArchLinux, в котором #KDE давным давно присутствует прямо в нативном, неизменённом виде.
Причём в KDE весьма разумно подходят к вопросу:
- обновления системы на базе снапшотов #btrfs
- с полнодисковым шифрованием диска через #LUKS
- загрузкой через #systemd-boot (поскольку #GRUB плохо поддерживает LUKS)
У самого несколько лет именно так и есть — обновления с автоматическими через #TimeShift снапшотами файловой системы (средствами btrfs) при накатывании обновлений или установке софта.
И полнодисковое шифрование LUKS, возможности которого нормально поддерживает лишь systemd-boot.
Т.е. пока #GNOME прожирает средства на всякую откровенную херню, в то же самое время #KDE заняты весьма годными делами. И лепят вполне современный дистрибутив, закладывая в него более чем разумные практики и вообще, и в том числе, ещё и с дистрибьюцией софта через #flatpak.
#crypto #lang_ru
hub.hubzilla.deHubzilla.de
#efi stub booting has been pretty damn simple and quick. The days of #systemdboot and #grub are gone, for me at least.
@opensuse's Tumbleweed is evolving with daily updates & integrating #systemdboot for improved boot performance & security. Dive into the challenges & directions on what a shift from #GRUB means. #openSUSE #Linux https://news.opensuse.org/2024/03/05/systemd-boot-integration-in-os/
openSUSE NewsNew systemd-boot Integration in openSUSEThere are several changes happening in openSUSE’s rolling release Tumbleweed on a daily basis and integrating systemd-boot into has been evolving. A shift fr...
I've done very little swapping of kernels, but just tried going from 6.6.10-76060610-generic to 6.5.0-15-generic, downgrading, so I could try a 6.5.0 specific driver for my MIPI camera.
I was able to boot into the 6.5.0 kernel, but I only had VGA resolution with no way to change that in the GUI, and I didn't bother testing the camera.
What did I do wrong? I'm guessing there was something very simple I didn't know to look for.
I don't like getting my documentation from reddit, but as PopOS uses systemd-boot, I followed the instructions here
https://www.reddit.com/r/pop_os/comments/guej8v/tutorial_switchchangeswap_kernels/
I installed the 6.5.0 kernel using Synaptic.
For a #manjaro system currently running #grub, do you think #systemdboot would be an upgrade I should consider? I don't have any problems with GRUB per se, but somehow to me it always feels a bit out of place, if that makes any sense. What is your #bootmanager of choice? #linux
Finally made the switch on my desktop system and installed #EndeavourOS to finally move away from #Manjaro. Quite happy with their decision to move to #Plasma as default DE and the default package choices. Also, this is my first time using #systemdboot instead of #GRUB, the first being the default choice in Endeavour. Also loving the fact that I don't have to install any additional stuff, everything works just fine out of the box. Did some quick gaming tests running #Cyberpunk2077, #AgainstTheStorm and #PortalRevolution, all running perfectly fine. 
Continued thread
Omar Two Tone
following up on this issue in #endeavouros the only workaround that I found was to use a CLI tool called: "efibootmgr" changing the boot order by the System IDs before reboot, so in that way I can see Kali Linux with its grub every time that I have to use it. if there's a better approach, let me know! 
Continued thread
Ohai, that instantly worked on the first reboot attempt 
Cool, so now I have #Fedora booting with #systemdboot from #BCacheFS with the root and home each in it's own subvolumes. 
Continued thread
Ok, first attempt I did now, was the root being directly on the top of the bcachefs partition. 
Works fine using #systemdboot after adding bcachefs to the initramfs filesystems and disabling #selinux.
Next thing is: I want to have my root and home each in subvolumes. Atm this ends in an emergency shell where I have to do two bind mounts, then it boots up just fine.
I'll try to work around that with a script hooked in before the switch_root happens
Finally, I got my blog post/tutorial on switching from #Grub to #SystemdBoot done
https://9lukas5.gitlab.io/blog/Verzeichnis/2023/12_replace-grub-with-systemd-boot/index.html
Last weekend I switched my machine.
Prior to that, I tested the conversion on various distros/versions of @ubuntu and @fedora e.g.
Result is now a tutorial on how to convert your #Debian based or #Fedora system, in the hope you struggle less than me finding a working guide^^.
Huge thanks for that matter also goes to @sebastiaanfranken, from where I got most of my steps 
9lukas5.gitlab.ioReplace Grub with Systemd-Boot
More from 
9Lukas5 
Nachdem ich letztes Wochenende auf #SystemdBoot gewechselt und und da so viel Zeit rein investiert hab, bin ich diese Woche damit beschäftigt daraus einen #Blog Eintrag / #Tutorial zu machen 
Ich werd aber nicht fertig mit dem Scheiß!! 
Ubuntu 22.10ff hab ich jetzt mal zusammen geschrieben.
Jetzt muss ich das ganze noch um pre-22.10, Pop, Debian und Fedora ergänzen 
Ich geh jetzt ins Bett ey 
Ganzen Tag in VMs rumgespielt: #Ubuntu2004, #Ubuntu2204, #PopOs2204, #Fedora36, #Fedora38 und #debiantesting in einem Multi-Boot Setup von #Grub auf #SystemdBoot umgestellt. 
Verschiedene Problemchen dabei angetroffen, bis es am Ende funktioniert hat 
Am Ende voll confident mein Prod-System (F38) umgestellt.
Bootet
- Alles Grub zeugs entfernt
- #EFI-Booteinträge aufgeräumt (efibootmgr)
*zack*, bootet nicht mehr 
Auf den letzten Metern doch noch nen LiveSystem gebraucht 
Today I updated my #NixOS #NAS, updated the kernel to a newer lts release, enabled a daily export of #Paperless data that I drafted a few days ago on my mac, replaced #GRUB with #systemdboot and switched its #btrfs subvolume layout to the one I use on my desktop already.
All with absolute ease by just putting a few lines of text in some files and everything just simply worked. It's so #blissful.