Не так давно задался вопросом установки Debian на ноутбук 2019 года с UEFI, до это на ноутбуке стояла Ubuntu. Установка Ubuntu проходила гладко, образ писался с WIndows при помощи Rufus (пожалуй, наиважнейший писатель ISO образов для винды).
Ну так вот, захожу на официальный сайт Debian, скачиваю основной (с главной страницы) ISO образ размером 300 с лишним МБ. Записываю при помощи Unetbootin с Ubuntu и ...... ух ты! Невероятно неожиданно вываливается ошибка, гласящая, что установщик не нашел драйвера для сетевой карты.
Учитывая, что это ноутбук, техника современная, вероятно, драйвера проприетарные, я побрел на сайт Debian за образом с проприетарным софтом. Сейчас для Debian 11 подобные образы можно найти вот тут. Скачиваю, записываю при помощи того же Unetbootin, загружаюсь. И, на этот раз действительно неожиданно, вываливается та же плашка, ругающаяся на драйвера.
Примерно в то же время я нашел другую флешку сомнительного происхождения, где был записан также nonfree Debian (или, по крайней мере, что-то удивительно похожее на nonfree Debian), устаревший приблизительно на год (первая цифра в номере версии еще была актуальна, а вот вторая устарела выпусков на 6). Примечательно, что разметка на этой флешке была совершенно дурацкая (раздел точь в точь размером с ISO образ, очень маленький раздел и пустое место, в котором по каким-то загадочным причинам не получается создать новый раздел). С нее, на удивление, все установилось замечательно.
Тут можно было закончить, но вот перспектива зависить от одной флешки, которая в любой момент могла выйти из строя либо потеряться + сидеть всю жизнь на одной и той же версии Debian меня не устраивала, и пришлось разбираться, как кто-то записал эту флешку.
Я стал ругаться на Unetbootin и стал пробывать другие средства. Попробывал записать через винду при помощи Rufus, которым я записывал бубунту. Симптомы те же. Попробывал dd и встроенную в GNOME (а точнее GNOME диски) записывалку ISO образов (записывалка из GNOME дисков, по факту, чистый dd, поэтому результат один и тот же). После выхода в UEFI я увидел флешку, но после того как я поставил ее на первое место для загрузки - загрузка с флешки пропустилась и пошла загрузка обычной системы. Это первая вещь в этой статье, которую я толком-то объяснить не могу, но факт остается фактом: UEFI молча отказалось грузится с флешки, записанной через dd. Если кто-то сможет объяснить это явление в комментариях, буду признателен.
Далее я подумал, что возможно, что тогда человек, записывавший это флешку использовал немного другой образ (сам добавил туда какие-то пакеты и т.д.), после чего я попробывал скопировать флешку при помощи dd. Скопированная флешка загрузилась, но на этапе выбора сетевой карты вновь неожиданно выпала ошибка. Тут я впал в ступор, ведь две флешки, которые, по факту, были скопированы по байтово работают по-разному.
Я взял обе флешки и стал их исследовать через файловый мендежер. Через некоторое время я обнаружил удивительную вещь. В "правильной" флешке в образе по пути /firmware вместо самих .deb пакетов с софтом расположены пакеты, когда во второй флешке, которую я скопировал с первой при помощи dd, расположены пустые файлы размером 0 б, а это очевидно мешало установщику найти нужные драйвера. Это вторая вещь которую я не могу понять: как при по байтовом копировании возможны хоть какие-то различия. В Интернете ответа на этот вопрос я не нашел, и также буду признателен, если кто-то разъяснит в комментариях. Проверив образ через монтирование диска GNOME (тот же эффект можно получить глянув содержимое ISO образа через обычный архиватор), я увидел, что на самом деле в разделе /firmware лежат не пакеты, и, разумеется, не пустые файлы, а ссылки на конкретные пакеты, которые на самом деле лежат по другому пути в том же образе.
После всех этих чудес, я наконец-таки разгадал одну из тайн, которую хранит эта история, а именно способ, которым создали "правильную" флешку. Флешка была записана при помощи Etcher, это стало очевидно не только потому что записанная таким образом флешка работала как надо, а еще и потому что причудливая разметка флешки о которой я говорил ранее была точно такой же. Ссылки из образа не скопировались, но вместо ссылок появились копии пакетов, на которые эти ссылки ссылаются. Это, разумеется, довольно расточительная трата места, но за то это работает и установщик все находит, а не пустые файле по 0 б, которые мне дарили утилиты, в чьей надежности мне никогда не приходилось сомневаться. С тех пор на свой ноутбук, как и на остальные компьютеры, для установки Linux дистрибутивов я использую только Etcher (Windows системы он не понимает, остальные системы не приходилось ставить). Он хоть и требует много места из-за дублирования данных и запрещает использовать загрузочную флешку для чего-либо еще из-за очень странной разметки, но работает безотказно.
Вот такая вот странная история, делитесь предположениями о том, почему dd не копирует ярлыки и из-за чего UEFI не хочет грузится с флешек, записанных при помощи dd.
Комментарии (8)
nonickname227
26.12.2021 00:19+1Причины описанного поведения могут быть разные. Но, честно говоря, не очень понятна необходимость делать загрузочную флешку для только одного образа, когда есть ventoy. Ну разве только в случае если под рукой только флешка ограниченного размера.
Сделать можно из под винды/линукса/макоса. На флешке будет раздел, куда просто копируются абсолютно любые образы и при загрузке с флешки этот раздел сканируется и дается выбор какой образ грузить. И никаких танцев с бубном. Пока ни разу не подвел.
gth-other Автор
26.12.2021 00:28Замечание несомненно верное, но все равно очень много народу до сих пор пользуется тем же Rufus, Unetbootin, dd, GNOME-диски, Etcher и так далее, так что для ряда пользователей история будет полезная.
К сожалению, не могу сказать про то, как поведет себя Ventoy, ибо не пользовался: но уже сейчас почти полностью уверено могу сказать, что Secure Boot в UEFI будет ругаться, хоть это дело и отключается в настройках / решается добавлением ключей.
ky0
26.12.2021 00:24-1Это вечная проблема — «я создал(а) загрузочную флешку с помощью X, но она не работает». В наш продвинутый век easy2boot'ов и аналогичных софтин слышать такое немного странно. Зачем трогать заведомо рабочий образ, предоставляемый авторами дистрибутива, как-то его вкрячивая на флешку, если можно закинуть в первозданном виде — и тем самым избавиться от таких вот
статейголовняков, как описанный?gth-other Автор
26.12.2021 00:30Можно было бы, и можно было на старых BIOS при помощи dd, делал так и работало. Но вот у современного UEFI есть с этим ряд проблем, в моем же случае прошивка отказывалась грузится (таблица разделов и прочие ньюансы были выбраны правильно, проверял многократно).
V1tol
26.12.2021 01:00Если UEFI современный, то зачем вообще пользоваться какими-то утилитами? Флешку в FAT32 одним разделом и просто распаковываем образ на неё.
unsignedchar
Лучше вы. А то непонятно о чем статья.
gth-other Автор
История из жизни, возможно для кого-то любопытная. Несмотря на то, что о причине подобного поведения dd и UEFI не сказано (а вопрос о поведении UEFI и подобных утилит действительно серьезен, ибо найти людей, которые действительно разбирали исходники таких вещей и поняли их очень сложно), в статье приведены причины ошибок при записи при помощи Rufus и Unetbootin, а также решение для подобных случаев.
unsignedchar
Это не решение, а классический танец с бубном. Раньше делал по схеме А, и всё работало. Теперь почему то нет. По схеме Б почему то работает.
gth-other Автор
Не "почему-то", а вполне по понятной причине. Сервисы вроде Rufus и Unetbootin не умеют копировать ссылки. Ссылки не обрабатываются: они не понимают что это из-за чего получаются пустые файлы. Разработчики Etcher'a добавили в свой продукт поддержку ссылок, из-за чего копирование образа проходит нормально. Несвободный образ дебиана, в отличии от убунты, сильно полагается на ссылки в своем образе, из-за чего проблема с вышенаписанными программами выявилась только на дебиане.