Ubuntu 17.10 - может повредить ноутбуки Lenovo и Acer во время установки.

Ubuntu подвтердили баг, который может "окирпичивать" ноутбуки Lenovo и Acer при утсановке Ubuntu 17.10, убивая у них BIOS.

Вот список ноутбуков, кто может выйти из строя:

Lenovo B40-70

Lenovo B50-70

Lenovo B50-80

Lenovo Flex-10

Lenovo G40-30

Lenovo G50-70

Lenovo G50-80

Lenovo S20-30

Lenovo U31-70

Lenovo Y50-70

Lenovo Y70-70

Lenovo Yoga Thinkpad (20C0)

Lenovo Yoga 2 11" - 20332

Lenovo Z50-70

Lenovo Z51-70

Так же  Acer Aspire E5-771G.

Воздержитесь от установки на эти модели Ubuntu 17.10 как минимум до следуещего года. Такие примерные сроки озвучили разработчики.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147 - ссылка на баг.

GNU/Linux

1K постов15.5K подписчиков

Добавить пост

Правила сообщества

Все дистрибутивы хороши.

Будьте людьми.

Вы смотрите срез комментариев. Показать все
49
Автор поста оценил этот комментарий

ЭТО ОТНОСИТСЯ И К СТАЦИОНАРНЫМ СИСТЕМНЫМ БЛОКАМ!

Личный пример:

Ubuntu 16.04.3 LTS

Мат. плата Gigabyte B75M-D3V

После обновления пропали все USB (я решил что вышли из строя из за грозы, так совпало)

Воткнул pci-usb и стал жить дальше. Через какое то время при включении BIOS сообщил что поврежден и сам начал восстанавливаться (DualBIOS), после восстановления USB ожил вновь.


Только сейчас сопоставил ситуацию с этим текстом:

Hi all,
Basically on Lenovo Y50-70 after installing Ubuntu 17.10, many users reported a corrupted BIOS.
It's not possible to save new settings in BIOS anymore and after rebooting, the system starts with the old settings.
Moreover (and most important) USB booting is not possible anymore since USB is not recognized. It's very serious, since our machines do not have a CDROM.
раскрыть ветку (41)
39
Автор поста оценил этот комментарий

Вообще это относится к UEFI материнским платам, которые предоставляют возможность перезаписи прошивки BIOS из под системы. Почему именно убунту это затронуло, потому что если попробовать писать в /boot/efi/ из под root, то можно в биос записать все что тебе заблагоросудится. А конкретно текущий баг обусловлен тем, что установщик перезаписывает всю дерикторию /boot из под рута, и цепляет собой и BIOS...

раскрыть ветку (38)
49
Автор поста оценил этот комментарий

Еще один плюс в копилку обычного биос

раскрыть ветку (18)
43
Автор поста оценил этот комментарий
+1

Ненавижу эти триждыблядские UEFI с их свистоперделками в интерфейсе.

раскрыть ветку (9)
18
Автор поста оценил этот комментарий
Ну и зря. Как будешь обходить архитектурные ограничения DOS?
раскрыть ветку (8)
19
Автор поста оценил этот комментарий
А какие там ограничения? В схеме разметки DOS с LBA-32 они есть (размер жестких дисков), но никто не запрещает использовать другую схему разметки (например GPT или BSD) и на машине с Classic BIOS.


Да и жестких дисков больше 2 TiB до сих пор в практике весьма немного.


Никаких принципиальных ограничений для того, чтобы и дальше использовать классический BIOS нет. Но я согласен, что по многим параметрам он далёк от идеала. Только заменять его нужно было не на UEFI, а на OpenFirmware, которое было разработано раньше и работало гораздо прямее.

раскрыть ветку (6)
7
Автор поста оценил этот комментарий
Присоединюсь к вам. Непонятно, что мешает использовать gpt на современных ОС.
8
Автор поста оценил этот комментарий

BIOS не позволяет загружаться с дисков более 2 Тб, и тем более с GPT. BIOS застрял в 16-битном real-time режиме, чтобы загружать 32-битную или 64-битную основную систему, нужно поиздержаться в процессе загрузки. BIOS очень трудно научить новым технологиям (я вот помню, как долго сидел на IDE-режиме только потому что BIOS не умел в AHCI, несмотря на то что матплата его поддерживала). BIOS монолитен и не позволяет отключать/удалять ненужный функционал. BIOS не предоставляет прямой доступ к устройствам, давая рулить ими только через прерывания.

раскрыть ветку (4)
10
Автор поста оценил этот комментарий

Что значит, не позволяет? Да, обратиться через функции BIOS к секторам за пределами первых 2 TiB будет нельзя, но эти функции используются на ранних этапах загрузки. То есть да, BIOS boot partition нельзя размещать дальше первых 2TiB, но учитывая что она размером может быть около 1 мегабайта — не думаю что в этом есть какая-то проблема.


> и тем более с GPT.

Classic BIOS вообще пофиг на разметку, он этим не занимается.


> BIOS застрял в 16-битном real-time режиме

Есть такое, да. Но это не является фатальным недостатком, 20 лет пользовались и всё всех устраивало.


> BIOS очень трудно научить новым технологиям

Ну в таком случае сменили бы его на OpenFirmware. Зачем было изобретать новый костыль, который во многом хуже даже классического BIOS? Или под новыми технологиями ты понимаешь всякие графические интерфейсы и прочую хрень? Так чем её больше, тем хуже с надёжностью и безопасностью.


> BIOS не предоставляет прямой доступ к устройствам, давая рулить ими только через прерывания.

Да ладно? Устройствами через прерывания BIOS управляют только на начальной стадии загрузки.

раскрыть ветку (2)
2
Автор поста оценил этот комментарий
Не думаю что в этом есть какая-то проблема.

Проблема - не проблема, а Windows с BIOS на такой диск ты не поставишь.


Classic BIOS вообще пофиг на разметку, он этим не занимается.

Ну да, поэтому с GPT загружаться он давать не могёт.


Зачем было изобретать новый костыль, который во многом хуже даже классического BIOS?

Под новыми технологиями я подразумеваю прямую загрузку с сети (нет, не через ROM сетевой карты), быструю инициализацию видеоподсистемы (пора забыть про VGA и VESA), возможность обновлять прошивки из-под родной системы, а не в особом режиме BIOS-а через досовскую программу, поддерживать прямую загрузку с iSCSI и RAID-контроллеров, а не ждать инициализации прошивки нужного устройства. Новые технологии, в общем. Все то, что появилось после 1985 года.


OpenFirmware, насколько я помню, не обеспечивал обратной совместимости со всем legacy оборудованием x86-архитектуры. А EFI, прообраз UEFI, делал Intel, который эту совместимость обеспечил. Так что, кто делает железо, тот гегемон и диктатор воли.

раскрыть ветку (1)
8
Автор поста оценил этот комментарий

> Проблема - не проблема, а Windows с BIOS на такой диск ты не поставишь.

Это проблема Windows, а не Classic BIOS. Не стоит перекладывать с больной головы на здоровую. Возможность загружать ОС есть? Есть! Значит проблемы нет.


> Ну да, поэтому с GPT загружаться он давать не могёт.

Классический BIOS на разметку вообще не смотрит, загружает первый сектор носителя в память и запускает его и всё. А дальше хоть там GPT, хоть DOS mbr, хоть BSD disklabel — с этим разбирается уже конкретный загрузчик. Если в каком-то загрузчике не поддерживается конфигурация классический BIOS+GPT — это проблема этого загрузчика.


> я подразумеваю прямую загрузку с сети (нет, не через ROM сетевой карты)

А какая разница, через что, если работает?


> быструю инициализацию видеоподсистемы (пора забыть про VGA и VESA)

А как же совместимость с оборудованием, о котором ты упоминал? И вообще, по-твоему, если стандарт существует давно, значит он плохой?


> возможность обновлять прошивки из-под родной системы, а не в особом режиме BIOS-а через досовскую программу

Это как раз минус. По-хорошему прошивка должна обновляться только в специальном режиме, переход в который возможен только при физическом присутствии пользователя, а перед загрузкой ОС чип должен аппаратно переключаться в режим Read-Only, чтобы вирусы не запороть прошивку или прописаться в ней.


> поддерживать прямую загрузку с iSCSI и RAID-контроллеров, а не ждать инициализации прошивки нужного устройства.

Загрузка в принципе без этого возможна? Возможна.


> OpenFirmware, насколько я помню, не обеспечивал обратной совместимости со всем legacy оборудованием x86-архитектуры.

В EFI её тоже нет, а добавляется она через CSM (compatibility support modules). Кто мешал написать аналогичные модули для OpenFirmware?


> А EFI, прообраз UEFI, делал Intel

И зачем они делали свой костыль, а не взяли готовое решение?


Впрочем проблема не в стандарте UEFI, а в том, что производители прошивок его не соблюдают и кроме того пихают множество ненужных свистоперделок.

Автор поста оценил этот комментарий
Никто не говорит, что BIOS был идеален. И все понимают, что его нужно было менять на что-то новое как стандарт. Но не на то, на что в итоге поменяли...
Автор поста оценил этот комментарий

>архитектурные ограничения DOS


Конкретнее, пожалуйста. Вы про 640 кб хватит всем?

1
Автор поста оценил этот комментарий

еще один плюс к тем кто знает что он выполняет

5
Автор поста оценил этот комментарий
Зато грузиться уефи на 1 секунду быстрее и есть цветное меню!!!! да и вооще биос старый, надо менять, как так, что что-то годами не менялось?
раскрыть ветку (6)
4
Автор поста оценил этот комментарий

Была такая штука когда-то давно - WinBIOS, со значками и мышью (!). По тем временам (486 и первые пентиумы) это было дико круто.

Иллюстрация к комментарию
раскрыть ветку (3)
2
Автор поста оценил этот комментарий

У Фармозы в 2001 была плата с говорящим биосом, видел сам в живую.

раскрыть ветку (2)
Автор поста оценил этот комментарий
У гигабайта (?) были материнки, которые из биос могли сд-ромом управлять, как цд-плеер )
Автор поста оценил этот комментарий

Да-да, помню такую фишку у Асуса. Я чуть не поседел, когда при включении свежесобранного компа мне русским языком сообщают, что клавиатура не подключена.

11
Автор поста оценил этот комментарий
Самое смешное, что меню UEFI на многих компах выглядит точно так же как меню старых BIOS. Псевдографика и управление с клавиатуры.
раскрыть ветку (1)
3
Автор поста оценил этот комментарий
Та епт, я же в сарказм дал....
3
Автор поста оценил этот комментарий
Так в /boot/efi монтируется раздел диска, помеченный как EFI. В этом разделе хранятся загрузчики ОС. Это обыкновенный раздел диска. Как запись на диск может убить BIOS?
раскрыть ветку (2)
Автор поста оценил этот комментарий

Секундочку. Я может скажу чушь, но я имел дело с проблемой Ubuntu на ноутбуке Acer ES1-533. /boot/efi это же просто загрузчик, т.е. там лежит grub для efi. Другое дело есть создается раздел на диске /efi, причем он создается, что виндой, что линухой при установке. Там уже хранится файл что-то вроде Bootx64.efi, который и является загрузчиком grub. Я когда пытался запилить dualboot столкнулся с проблемой, что Ubuntu виснет на установке grub2, а дебиан встает, но uefi не видит загрузчика как раз в /efi/Debian/grubx64.efi

В итоге решилась проблема cp /efi/Debian/grubx64.efi /efi/Boot/grubx64.efi

раскрыть ветку (1)
Автор поста оценил этот комментарий

Это просто раздел диска с загрузчиками. Да, grub выступает в роли загрузчика. Ваша проблема возможно связана с тем, что BIOS не осуществляет поиск всех загрузчиков на диске, а просто обращается к ним через переменные. В переменных BootOption сохраняется путь к загрузчику. А в переменной BootOrder указаны индексы переменных BootOption в порядке их приоритета, согласно которому осуществляется загрузка. В вашем случае установщик Debian либо не добавил переменную BootOption, либо создал ее, но не поместил ее индекс в переменную BootOrder.Есть еще вариант, что ваша реализация UEFI просто игнорирует переменные и грузит первый попавшийся образ из директории /Boot.

Автор поста оценил этот комментарий

Не /boot/efi, а /sys/firmware/efi/efivars. В штатном режиме оно редактируется через efibootmgr и проблем никаких нет, но некоторые особо упоротые прошивки падают на определенном наборе параметров.

Автор поста оценил этот комментарий

У меня на ноуте UEFI (Acer Aspire V3-771G) и всё равно никаких проблем с это версией

раскрыть ветку (2)
2
Автор поста оценил этот комментарий

Не все UEFI позволяют писать биос из под системы.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Тут ребятишки сверху дискутировали на эту тему. Позволю цитатку:
======
"возможность обновлять прошивки из-под родной системы, а не в особом режиме BIOS-а через досовскую программу"
Это как раз минус. По-хорошему прошивка должна обновляться только в специальном режиме, переход в который возможен только при физическом присутствии пользователя, а перед загрузкой ОС чип должен аппаратно переключаться в режим Read-Only, чтобы вирусы не запороть прошивку или прописаться в ней."
#comment_102799374
=====
так вот, к чему это я. ТРИЖДЫБЛЯДСКИЙ UEFI!
Автор поста оценил этот комментарий

И как он перезаписывает если бут вроде как находиться на диске


/dev/sda0 ---> /boot

раскрыть ветку (11)
Автор поста оценил этот комментарий

/ - union mount

модуль ядра подключает efi vars

1
Автор поста оценил этот комментарий
akazakou@zx386:~$ sudo mount
...
/dev/sda2 on /boot type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
...

Тут нужно учитывать что у меня только один HDD. Значит он воспринимает BIOS как обычный диск, и соответственно назначает ему устройство в /dev


Аппарат: Lenovo Ideapad Y700

раскрыть ветку (9)
Автор поста оценил этот комментарий

странно что с той же буквой,а не sdb какой-нибудь.  uuid у винта и уефи должны быть все же разные?


Хорошо хоть ro стоит.



Если сначло на винт поставить линукс, а потом воткнуть его в ноут ?


И получается у других дистрибутивов такой проблемы нет ?


У меня правда нету устройств с уефи, поэтому мого более смело эксперементивроать.

раскрыть ветку (8)
13
Автор поста оценил этот комментарий

Эм. Ребят, вы чего?

/boot/efi - обычный раздел на диске, он никак не связан с вашей материнкой. Его задача - хранить файлы, которые потом uefi найдёт и запустит.

Собственно, с флешем в uefi взаимодействует программа efibootmgr, которая и занимается записями загрузочными. Можете хоть весь диск переформатировать, флеш uefi не затронете.


Здесь вообще ситуация другая - баг в драйвере, который написал intel. Фикс временный (отключение драйвера) уже в пакетах есть.

раскрыть ветку (7)
6
Автор поста оценил этот комментарий

Ну, наконец-то хоть кто-то за баг начал пояснять. что за драйвер-то?

раскрыть ветку (2)
2
Автор поста оценил этот комментарий

Драйвер для работы с spi флеш-памятью под линуксом. Нужен, в общем-то, для кучи отладочных плат и (потенциально) обновления uefi из существующей ОС (как это некоторые производители делают в windows).

Автор поста оценил этот комментарий

Написано какой то из intel-spi-* Какой точно не указано.

1
Автор поста оценил этот комментарий

Ну хоть есть адекватные люди. А то с этого заплюсованного высера akazakou про "убийство BIOS через запись на диск" я был просто ошарашен. Это же надо было додуматься до такого!

раскрыть ветку (3)
Автор поста оценил этот комментарий

https://www.phoronix.com/scan.php?page=news_item&px=UEFI...


А вообще, то что UEFI хранилище монтируется как устройство в виде диска, есть только особенность реализации. Еще до этого база, помнится мне были сообщения о брик устройствах как раз из-за этой проблемы.

раскрыть ветку (2)
Автор поста оценил этот комментарий
Сначала разберитесь с кашей в своей голове, а потом пускайтесь в рассуждения. Не нужно людей вводить в заблуждение своими домыслами. Вы даже статью не читали, которую приводите. И там, и в оригинальной новости, на которой основывается текущий пост, достаточно ясно описана причина проблемы.
раскрыть ветку (1)
Автор поста оценил этот комментарий

Описана проблема в том, что изначально параметры EFI монтировались в RW режиме.


Mounting efivarfs read/write by default can lead to accidental deletion of the EFI variables. It was already reported on Arch Linux forums, that running 'rm -rf' over a directory structure with mounted efivarfs did actually "hard-brick" some MSI notebook.

Оригинальная новость текущего поста действительно мало относится к моему заявлению, т.к. там ситуция несколько другая. Но я всего лишь напомнил, что при помощи команды "rm -rf /" можно было брикнуть свой аппарат.


Но а вы, в свою очередь утверждаете что:


высера akazakou про "убийство BIOS через запись на диск"

При этом я ниразу не говорил про убийство биоса через запись на диск. Я лишь привел ответ на утверждение


/boot/efi - обычный раздел на диске, он никак не связан с вашей материнкой.

Так что сначала прокачайте себе скилл внимательности.

5
Автор поста оценил этот комментарий

Что за обновление не помню, гроза была 5.09.17, значит или в этот день или чуть ранее.

Признаюсь чудесное исцеление USB очень удивило, но объяснить я его тогда не смог, пока не прочел этот пост.

Автор поста оценил этот комментарий
Скорее всего у вас тупо побился BIOS, который потом и восстановился из DualBIOS (фактически неизменяемого бэкапа).

Это могло произойти от чего угодно. Скачок напряжения, замыкание, и даже банальная севшая батарейка CMOS. Если её вынуть и оставить материнку без электрической сети на некоторое время - результат будет тот же, битая контрольная сумма BIOS и предложение восстановить.


А по теме, вам правильно пишут в этой ветке, что проблема из топика связана именно с UEFI.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку