После двух лет разработки представлен стабильный релиз модульного многоплатформенного менеджера загрузки GNU GRUB 2.06 (GRand Unified Bootloader). GRUB поддерживает широкий спектр платформ, включая обычные ПК с BIOS, платформы IEEE-1275 (оборудование на базе PowerPC/Sparc64), EFI-системы, RISC-V, оборудование на основе MIPS-совместимого процессора Loongson 2E, системы Itanium, ARM, ARM64 и ARCS (SGI), устройства, использующие свободный пакет CoreBoot...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55301
А интересно, LILO живой или ушел в мир иной?
Он работает, или вам его тоже переписать на Lisp и непонятные динамические конфиги, которые хз как настраивать?
А в эпоху UEFI загрузчики вообще уже отжили свое, rEFInd наше все.
А в эпоху UEFI - в черную эпоху ненужного нормальному человеку UEFI.
Там наворотили хаоса и secure boot, но концептуально почему uefi настолько "Чёрная"? Вроде почти хороший тип прошивки.
Есть вполне живой загрузчик EXTLINUX - syslinux для ext2/ext3/ext4/btrfs/xfs/f2fs
В дебиане живой, как в других дистрах хз.
https://packages.debian.org/en/sid/extlinux
Инструкция как обгадить что-то, не имея адекватных аргументов:1. Найти то, что вам не по душе.
2. Причислить себя к «нормальным», не приводя, естественно, никаких аргументов.
3. Сказать что нечто, неприятное вам нормальным людям не нужно. Желательно не приводя аргументов.
4. PROFIT.
> или вам его тоже переписать на Lispна Rust, пожалуйста
И на DBus завязать
systemd-lilod
systemd-boot уже есть
Хмхм, не знал, что они gummiboot удочерили.
Надо попробовать.
Ну не смешно уже
> А в эпоху UEFI загрузчики вообще уже отжили свое, rEFInd наше все.А rEFInd разве сам по себе не загрузчик?
Вообще, можно юзать ядро с EFI Stub и грузить его безо всяких загрузчиков.
refind всё же bootmanager.
>Вообще, можно юзать ядро с EFI Stub и грузить его безо всяких загрузчиков.Всячески одобряю! Собственно это и есть самый грамотный способ загрузки, особенно если нужна реальная секьюрность со своими собственными сертификатами и подписью ядра.
>секьюрностьА полнодисковое шифрование ты как без граба сделаешь? Буткиты никто не отменял.
Товарищ, накой вам пёс сдалось шифровать весь диск? Для использования UEFI вам всё равно требуется загрузочный раздел в FAT32, на нём и лежит подписанное вами же ядро, а значит скомпрометировать вас уже не получится никак. Дальше идёт прямая загрузка, уже точно вашего ядра, которое и монтирует зашифрованный том.
Товарищ, накой вам пёс сдалось шифровать весь диск? Для использования UEFI вам всё равно требуется загрузочный раздел в FAT32, на нём и лежит подписанное вами же ядро, а значит скомпрометировать вас уже не получится никак. Дальше идёт прямая загрузка, уже точно вашего ядра, которое и монтирует зашифрованный том.
да блин...
> Товарищ, накой вам пёс сдалось шифровать весь диск? Для использования UEFI вам
> всё равно требуется загрузочный раздел в FAT32, на нём и лежит
> подписанное вами же ядро, а значит скомпрометировать вас уже не получится
> никак. Дальше идёт прямая загрузка, уже точно вашего ядра, которое и
> монтирует зашифрованный том.А кто будет проверять подпись ядра, если это EFISTUB и потенциально скомпрометированное ядро сразу же выгружается в оперативку и начинает работать?
Храним /boot на флэшке, флэшку - под подушкой, утку в зайце^W^W^W и спим спокойно.
На всякий случай поясню, что всё описанное выше, подразумевает, что ваш inittarm, который вкорячивается вместе с ядром в EFI Stub должен чекнуть сигнатуры полученные от UEFI, прежде чем запрашивать пароль.
> На всякий случай поясню, что всё описанное выше, подразумевает, что ваш inittarm,
> который вкорячивается вместе с ядром в EFI Stub должен чекнуть сигнатуры
> полученные от UEFI, прежде чем запрашивать пароль.
>inittarmСтесняюсь спросить, а что это? Даже гугл не знает. Если речь про initramfs, то что мешает скомпрометировать и ее?
А чем полнодисковое шифрование поможет от буткитов? Что помешает малвари спросить у пользователя пароль для расшифровки /boot, а потом запатчить загрузочный образ?Как в /boot может появиться секрет, требующий шифрование? Разве что положить в initramfs ключ для расшифровки всего остального диска, и использовать TPM с Secure Boot, чтобы защититься от буткитов. Но в случае работающего TPM лучше хранить ключ там, а /boot держать незашифрованным.
> А чем полнодисковое шифрование поможет от буткитов?Твое ядро лежит на зашифрованном разделе, и без расшифровки раздела подменить или что-то с ним сделать никак не получится. На биос поставить пароль и сделать secure boot, чтобы с грабом на ESP ничего не сделали.
Пароль на BIOS - это совсем не серьезно. Максимум, как свидетельство канарейки.
rEFInd не загрузчик, он просто перенаправляет и все. Дистрибутив без EFI Stub он не загрузит.
rEFInd не умеет в XFS, F2FS и кучу других ФС, а уж тем более в LVM/LUKS. Этого уже достаточно, чтобы его выкинуть.
> А в эпоху UEFI загрузчики вообще уже отжили свое, rEFInd наше все.Зачем вообще rEFInd если UEFI-шный "биос" сам всё находит и загружает? Не для этого-ли его изобретали?
>LILO живой или ушел в мир иной?Последняя версия lilo-24.2 (22 ноября 2015)
Была ещё попытка создать elilo, но в 2014 году проект сдох...
Сам грущу по lilo...
Этот жирнющий GRUB с его перенавороченной архитектурой бесит...
Мне grub-1 нравился. Выпилили из Генты.
loadlin.com - 4ever.
loadlin.EXE или LINLD.com. второй намного лучше, работает и с большими ядрами и initrd и с другими вещами, что не может loadlin
lilo как работал так и работает, зачем его обновлять?
elilo изначально не нужен был, ибо EFI Stub.
Вас все бесит
Живее всех живых, пользовался им с пол года, но месяц назад поменял сдыхавший хард и снова на Груб ушел.
>По умолчанию отключена утилита os-proberОтлично. Задолбался каждый раз добавлять вручную.
Зачем нужен этот кривой перегруженный монстр, когда есть systemd-boot?
Найс троленк
Серьёзно?
Stub??? )))
Нужен для тех, у кого не Arch Linux, и/или у кого всё ещё нет EFI в 2021 году. Systemd-boot не работает если название ядра меняется каждое обновление, как это происходит, например, в Ubuntu. В Arch Linux же название ядра не меняется до тех пор, пока сам вручную не заменишь ядро на другую разновидность (например, пакет linux на пакет linux-lts).
>> Systemd-boot не работает если название ядра меняется каждое обновление, как это происходит, например, в Ubuntu.работавет через pacman hooks
В убунту нет pacman
чуть не внимательно прочитал. Так то в убунту есть post-install hook при создании пакетов которым можно делать тоже самое
>В убунту нет pacmanВ убунту нет смысла
ЧТо?"и/или у кого всё ещё нет EFI в 2021 году"
Ставьте Tincore и работайте себе с EFI системой.Grub не только под загрузку с BIOS систем, но также и с EFI.
systemd-boot форк форка, можно, но не нужно)
> не заменишь ядро на другую разновидность (например, пакет linux на пакет linux-lts)Зачем "менять", когда оба пакета можно поставить рядом?
Это не совсем так. В Арче название для initramfs/initrd определяется хуками из пакета mkinitcpio. Их можно и переопределить через /etc/pacman.d/hooks. А если использовать другой генератор, например dracut, который используется в других дистрибутивах, то хуки и вовсе, пишутся самостоятельно.
systemd-boot научился грузить ядра с ext4? (не ради холивара спрашиваю)
С чего душе угодно
С LUKS тоже?
А почему даунвоутнули? Вполне хороший вопрос.
У меня /boot{,/EFI} отдельным разделом, /{,home} на LUKS2. systemd-boot (без GRUB2) более, чем достаточно для загрузки.
научился, но при условии что данные не зашифрованы. и здесь только граб может помочь из всех существующих загрузчиков
Установленная система и "хомяк" могут быть зашифрованы.
всё может быть зашифровано кроме /boot/efi но грузить шифрованный /boot с другого раздела может только граб
И Grub никак не сможет помочь, если загрузка в EFI режиме. Потому-что /boot/EFI не может быть зашифрован by design. Все претензии к Microsoft.
само собой говорим об uefi
но речь не о /boot/EFI это понятно что его шифровать не выйдет
речь о шифрованном /boot на другом разделе
А есть какой-то практический смысл шифровать /boot, если загрузчик из /boot/EFI всё равно может быть скомпрометирован? Проще же весь /boot раздел хранить отдельно от диска, на шлешке, или подписывать файлы (initramfs, etc) на нём в дополнение к UEFI. В этих файлах обычно ничего секретного нет, если их прочитают. А если перезапишут - мы узнаем.
Народ, что может быть, какой линукс не ставил, запускаются долго, у меня ссд, выключается монитор и проходит около 1 мин, и тогда загружается на раб стол. Это у меня так или у всех?
Для ссд всё же довольно долго грузится, а монитор выключается из-за того, что мышкой не шевелите. Обычно надо на такое минут 5-10, но у вас кажется крутой монитор или грузится уж больше чем минута.
Монитор гаснет, и индикатор тоже, дело не в шевелении мышкой, я думаю, может дело именно в GRUB
А если в конфиге груб выставлено много времени на выбор ядра/ос?
Не пытайтесь помочь этому человеку самостоятельно - бригада санитаров уже в пути.
Какое-то экзотическое оборудование, вероятно, плохо поддерживаемое драйверами в Linux. Загрузка с SSD должна быть быстрой.
В любой непонятно ситуации смотри логи.
Прочекай оборудование (тот же ссд).
Судя по тому что ты ставил разные "линуксы", то дело не в системе инициализации, но я бы все равно на всякий случай проверил когда и как долго сервисы запускаются.
смотри логи
вытяни нетворк шнурок при загрузке
>Это у меня так или у всех?У меня тоже так:(
Возможно глупость скажу, но я бы проверил соответствие UUID дисков в fstab - было подобное зависание после кучи установок всяких дистров (несоответствовал UUID swap-раздела)
Смотри логи.
Очень похоже, что в системе есть какая-то железяка (или контроллер на какой-то железяке), к которому нет драйвера рабочего. И вот в течение этой самой минуты происходит поиск (безуспешный) этого драйвера.Один из самых известных примеров — usb-хаб на видеокартах от NVIDIA. Не знаю, как сейчас, а год назад он точно не поддерживался даже последними ядрами. При этом у самой видеокарты usb-выходов может и не быть, но контроллер присутcтвует. Решение — заблэклистить контроллер.
Ещё вариант — какой-то демон не стратует. Сетевой ресурс не доступен во время загрузки или ещё чего. Вот пока таймаут systemd не выйдет (тоже настраивается), загрузка будет приостановлена. А монитор, вероятно, успеет за это время выключиться.
я предполагаю что дохнет ssd. поставьте нормальную железку с блинами того же или большего размера, через clonezilla перекиньте содержимое и вперед.
Выломай из системы все няшные заставочки, которые рисуют картинки с самых ранних этапов загрузки, пускай загрузка выглядит как пингвины, сидящие на бегущих строчках. Вовсе не обязательно понимать все эти строки, но как минимум ты будешь видеть границы этапов загрузки (типа UEFI закончил, загрузчик теперь... а теперь ядро грузится, а вот оно гуй стартануло), что само по себе будет сужать пространство возможных диагнозов. Кроме того, если оно будет подвисать на какой-то строчке, то ты её сможешь сфоткать и отправить на экспертизу каким-нибудь форумным экспертам. А если оно будет все строчки прятать, прежде чем задуматься, то ты сможешь снять видяшку и отправить её на экспертизу форумным экспертам.Правда, увы, я не могу подсказать, как заставки выломать, потому что не знаю. Никогда их не пытался приделать, и никогда от них не избавлялся. Ну разве что от биосовой. Но если ты поспрашаешь, тебе расскажут. Может быть гугл может подсказать.
Обычно нажать в процессе загрузки esc достаточно, чтобы все эти заставки скрыть к такой-то матери
поменяй свой ssd на hdd 5400 об/мин
у меня на последнем как раз 60 секунд грузится дистр
Крутится там в загрузке какой-нить багованный сервис который задерживает всё остальное
Его написали, чтоб Виндоус загружать. Вернее, чтобы можно было при рабочей виндоус какой-нибудь линукс иногда загрузить. Почему этот невменяемый многомногомегабайтный загрузчик для дуалбутчиков остается по умолчанию везде? Дуалбутчики давно уже линуксы всякие под виндоус в виртуалбоксе ганяют? В чем смысл существования этого кошмара?
С Lilo тоже грузится Винда в два счёта. Писали груб2 для UEFI.
Перед груб2 был просто груб. Для поддержки виндовсого уефи модернизировали до груб2, добавив много мегабайт без инструкции не разберешься чего и непонятно для чего. Уже вот линукс прямо в виндоусе запускается, а тут кто-то продолжает выпускать новые версии груба. В чем прикол?
Линукс прямо в виндоусе - это изврат
> В чем прикол?Прикол в том, что ты — виндузятник, который припёрся на ресурс с названием OpenNet и чего-то тут пытаешься пропагандировать.
Systemd-boot умеет запускать Windows в dual-boot с GNU/Linux.
> запускать WindowsНикто не писал, что "не нужно"? Или модераторы потерли?
Скорее наоборот винду под виртуалкой. Гонять линукс в виртуалке на винде это как из тюремной камеры смотреть как живут в райском местечке.
Или хранить денежки на поле чудес.
> Почему этот невменяемый многомногомегабайтный загрузчик для дуалбутчиков остается по умолчанию везде?Потому, что гибкий и мощный, способен завести очень сложные конфигурации, имеет приличный CLI, из которого (пусть и с гуглом) можно загрузить систему, если всё сломалось.
То, что он большой, имеет мало значения в выборе дефолта, всё равно исчисляются размеры максимум мегабайтами. Хотите проще и быстрее - ставьте Syslinux или systemd-boot для UEFI.
Когда всё сломалось, получить помощь гугла бывает затруднительно.
Livecd c той же убунтой и а сеть, в чем проблема?)
с телефона чтоле попробуй, они теперь тоже умеют в гугл )
Воддийствитильно...
Я в дуалбуте использую виндовый загрузчик (чтобы Шиндовс-упдейт не угробил мне линукс), и считаю, что это самый надёжный вариант.
Хотя, wait, oh shi-, он же грузит груб! :D
А груб грузит всё.
Груб это мощь!
> А груб грузит всё.При загрузке винды GRUB так же торкнет виндовый загрузчик. Так что не надо про всё, граб грузить линь, виндовый - винду.
>> SBAT (UEFI Secure Boot Advanced Targeting)Extended Advanced Unbreakable Trusted Secure Boot Extension (c)
Universal Protected Safe Secure Loader (R)
Restricted Isolation Boot Technology (tm)
Secure Signed Boot Sequence Layer
Enriched System Preload Image Hub
Enhanced Reliable Boot Module
Linux Standart Boot Management Kernel Interfaceну ну
"Обещали безопасность, безопасность есть, а то что защищать будет не обещали" (C)
>релиз ОС GRUBПочинил.
> Добавлена поддержка формата шифрования дисков LUKS2Джва года ждал.
Теперь можно не иметь отдельный незашифрованый раздел под /boot
Зачем не зашифрованный? Можно было v1 использовать.
А чем переход на luks2 здесь поможет?
а что не Верный фуллдрайв?
И ещё ~джва~ года подождать осталось, чтобы argon2i (который в luks2 по умолчанию) добавили.
Предвкушаю как хомяки пойдут биться лбом. Сейчас можно использовать только старый метод pkbf2 для ключей.
Так, вроде, патчи на LUKS2 ещё два года назад и смержили. Даже в Арч бэкпортировали. А сейчас просто официальный релиз вышел. Неспеша.
хз федора якобы LUKS1 поддерживает, когда в инсталлере выбираешь зашифровать /boot пишет бут не может быть зашифрован, WTFи еще допустим наконец все починили, кто защитит граб от подмены? нужен хотя бы sedutil и TCG Opal, т.е. двойное шифрование аппаратное + LUKS
secure boot насколько я знаю с линухой не работает, там грузится только shim
и да LUKS - тормозной, процентов 30-40 скорости дисковой подистемы теряется, что не есть хорошо, тот же DiskCryptor под вин жрет 3-5%
меня прилично расстраивает такое положение вещей для линукс
Загрузку с F2FS таки добавили или нет? Несколько лет обещают, а воз и ныне там.
grub-2 давно грузится с f2fs, ради того и перешёл с lilo.
> grub-2 давно грузится с f2fs, ради того и перешёл с lilo.А ну чудно. А то из их списка рассылки совершенно невозможно понять какие фичи реально реализованы.
этой зимой использовал lilo для загрузки с nvme на китайской материнке с ксеоном с алиэкспресса. Без какого-либо умысла, просто столкнувшись с какими-то сложностями груба, решил дать шанс старому лило. Без проблем. Поставил и забыл.
> LUKS2ок держите в курсе
> Прекращена поддержка коротких MBR gap (область между MBR и началом дискового раздела, в GRUB используется для хранения части загрузчика, не умещающейся в сектор MBR).Это очень плохо. Я туда пихал core.img + модули_расшифровки_/boot + публичный_ключ_и_модули_проверки_подписей
> Устранены уязвимости BootHole и BootHole2.
А их и не было, из-за дополнительных проверок загрузчик разжирел и перестал влазить в "область между MBR и началом дискового раздела"!!! Это умышленное вредительство.
> Реализован механизм lockdown
Звучит заманчиво.
а раздел boot с btrfs считает по дефолту или опять шаманить?