Ubuntu 17.10 поврежда BIOS-а в някои лаптопи на Lenovo, Acer и Toshiba
Компанията Canonical отдръпна излязлата през месец октомври дистрибуция Ubuntu 17.10 и махна съответния линк от уеб страницата за евакуиране. Причината е сериозен бъг, повреждащ BIOS-а в някой модели преносими компютри на Lenovo и един модел на Acer . Списъкът с потърпевшите устройства се прецизира и добавя.
Дефектът е прекомерно противен и се състои в това, че преносимият компютър не зарежда, новите настройки повече не могат да се запишат, и след рестартиране, преносимият компютър употребява старите настройки.
И още по-зле, USB устройствата стопират да се разпознават и стартирането от USB не е допустимо.
Според описанията на бъга, той стартира да се демонстрира след активирането на драйверите intel-spi-* в ядрото. Изглежда че работата върху тези драйвери не е довършена и те още не са подготвени за потребителските компютри.
За отбягване на този проблем се предлага деактивирането на драйверите intel-spi-*. В описанието към бъга се споделя, че следствията от деактивирането са минимални. “Слабо евентуално е някой в действителност да направи нещо, че да се наложи да употребява този драйвер“.
Ето към сегашен ден листата с потърпевшите преносими компютри:
Lenovo B40-70Lenovo B50-70Lenovo B50-80Lenovo Flex-3Lenovo Flex-10Lenovo G40-30Lenovo G50-70Lenovo G50-80Lenovo S20-30Lenovo U31-70Lenovo Y50-70Lenovo Y70-70Lenovo Yoga Thinkpad (20C0)Lenovo Yoga 2 11″ — 20332Lenovo Z50-70Lenovo Z51-70Lenovo Ideapad 100-15IBYAcer Aspire E5-771G
Списъкът се добавя, и в мненията към бъга се загатва и преносимия компютър Toshiba L50B-23G.
В редица конгреси се натрупаха недоволства от потребителите, тъй като в по-новите преносими компютри няма CD-ROM и системата не може да зареди.
Особено доста са недоволствата във форумите на Lenovo. Това е изключително неприятно, тъй като точно преносимите компютри Lenovo ThinkPad се предлагат за работа с Linux, а в уеб страницата на Canonical той е включен в листата с публично поддържаното съоръжение.
По принцип, допустимо е препрограмирането на BIOS и връщането му в предходното положение благодарение на програматор, само че това е нетривиална и рискована процедура. А и надалеч не всеки консуматор има програматор. Ето за какво, може да бъде разбрано мощното неодобрение на хората, сблъскали се с този проблем. “Това е недопустимо, одеве моят Lenovo G50-80 се трансформира в тухла” – написа един от потърпевшите в мненията към бъга в уеб страницата на Canonical.
Току що в мненията се появи информация, че никаква щета на BIOS-а няма, а се заключва опцията за запис в SPI Flash чипа. Явно това се случва при намесата на този модул в Linux ядрото. Оказа се, че записът на данни в SPI Flash е хардуерно заключен и никакви настройки в BIOS-а няма по какъв начин да работят, тъй като те се записват точно там. Програматорът също няма да помогне. Налага се физическата подмяна на чипа…
Canonical интензивно работи с Lenovo с цел да открие същинската причина на казуса и да показа пач. Подготвят се нови дискови облици на Ubuntu 17.10 с актуализирано ядро, които не повреждат BIOS-а.
За страдание, новите дискови облици с нищо няма да оказват помощ на хората, конфигурирали Ubuntu 17.10 и развалили своя BIOS. В краен случай може да се наложи преносимия компютър да се носи в сервиз за подмяна на дънната платка.
Но в случай че преносимият компютър въпреки всичко зарежда нещо, може да се опита процедурата, разказана във форума за техническа поддръжка на Lenovo.
Това е известие на консуматор, който също изгубил опцията да съхранява новите настройки на BIOS, както и да зарежда от USB.
Първото нещо, което този консуматор прави, е да ревизира последователността на зареждане на EFI. Това се прави благодарение на командата:
efibootmgr -v
В неговия случай последователността на зареждане наподобява по следния метод:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,2001,2002,2003
Boot0001* antergos_grub HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(EFIantergos_grubgrubx64.efi)
Boot0002* Windows Boot Manager HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(EFIMicrosoftBootbootmgfw.efi)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
Това значи, че първи се зарежда grubx64.efi от досието antergos_grub и от инструкции в EFI диск.
Логично е да се допусна, че можем да управляваме зареждането, променяйки файловете в досието antergos_grub. Потребителят просто заменил информацията в тази директория с информацията от boot мениджъра rEFInd, като преди този момент преименувал refind_x64.efi на grubx64.efi. След тази интервенция, при стартирането на преносимия компютър се появява общоприетото започващо меню на rEFInd.
Дефектът е прекомерно противен и се състои в това, че преносимият компютър не зарежда, новите настройки повече не могат да се запишат, и след рестартиране, преносимият компютър употребява старите настройки.
И още по-зле, USB устройствата стопират да се разпознават и стартирането от USB не е допустимо.
Според описанията на бъга, той стартира да се демонстрира след активирането на драйверите intel-spi-* в ядрото. Изглежда че работата върху тези драйвери не е довършена и те още не са подготвени за потребителските компютри.
За отбягване на този проблем се предлага деактивирането на драйверите intel-spi-*. В описанието към бъга се споделя, че следствията от деактивирането са минимални. “Слабо евентуално е някой в действителност да направи нещо, че да се наложи да употребява този драйвер“.
Ето към сегашен ден листата с потърпевшите преносими компютри:
Lenovo B40-70Lenovo B50-70Lenovo B50-80Lenovo Flex-3Lenovo Flex-10Lenovo G40-30Lenovo G50-70Lenovo G50-80Lenovo S20-30Lenovo U31-70Lenovo Y50-70Lenovo Y70-70Lenovo Yoga Thinkpad (20C0)Lenovo Yoga 2 11″ — 20332Lenovo Z50-70Lenovo Z51-70Lenovo Ideapad 100-15IBYAcer Aspire E5-771G
Списъкът се добавя, и в мненията към бъга се загатва и преносимия компютър Toshiba L50B-23G.
В редица конгреси се натрупаха недоволства от потребителите, тъй като в по-новите преносими компютри няма CD-ROM и системата не може да зареди.
Особено доста са недоволствата във форумите на Lenovo. Това е изключително неприятно, тъй като точно преносимите компютри Lenovo ThinkPad се предлагат за работа с Linux, а в уеб страницата на Canonical той е включен в листата с публично поддържаното съоръжение.
По принцип, допустимо е препрограмирането на BIOS и връщането му в предходното положение благодарение на програматор, само че това е нетривиална и рискована процедура. А и надалеч не всеки консуматор има програматор. Ето за какво, може да бъде разбрано мощното неодобрение на хората, сблъскали се с този проблем. “Това е недопустимо, одеве моят Lenovo G50-80 се трансформира в тухла” – написа един от потърпевшите в мненията към бъга в уеб страницата на Canonical.
Току що в мненията се появи информация, че никаква щета на BIOS-а няма, а се заключва опцията за запис в SPI Flash чипа. Явно това се случва при намесата на този модул в Linux ядрото. Оказа се, че записът на данни в SPI Flash е хардуерно заключен и никакви настройки в BIOS-а няма по какъв начин да работят, тъй като те се записват точно там. Програматорът също няма да помогне. Налага се физическата подмяна на чипа…
Canonical интензивно работи с Lenovo с цел да открие същинската причина на казуса и да показа пач. Подготвят се нови дискови облици на Ubuntu 17.10 с актуализирано ядро, които не повреждат BIOS-а.
За страдание, новите дискови облици с нищо няма да оказват помощ на хората, конфигурирали Ubuntu 17.10 и развалили своя BIOS. В краен случай може да се наложи преносимия компютър да се носи в сервиз за подмяна на дънната платка.
Но в случай че преносимият компютър въпреки всичко зарежда нещо, може да се опита процедурата, разказана във форума за техническа поддръжка на Lenovo.
Това е известие на консуматор, който също изгубил опцията да съхранява новите настройки на BIOS, както и да зарежда от USB.
Първото нещо, което този консуматор прави, е да ревизира последователността на зареждане на EFI. Това се прави благодарение на командата:
efibootmgr -v
В неговия случай последователността на зареждане наподобява по следния метод:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,2001,2002,2003
Boot0001* antergos_grub HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(EFIantergos_grubgrubx64.efi)
Boot0002* Windows Boot Manager HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(EFIMicrosoftBootbootmgfw.efi)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
Това значи, че първи се зарежда grubx64.efi от досието antergos_grub и от инструкции в EFI диск.
Логично е да се допусна, че можем да управляваме зареждането, променяйки файловете в досието antergos_grub. Потребителят просто заменил информацията в тази директория с информацията от boot мениджъра rEFInd, като преди този момент преименувал refind_x64.efi на grubx64.efi. След тази интервенция, при стартирането на преносимия компютър се появява общоприетото започващо меню на rEFInd.
Източник: kaldata.com
КОМЕНТАРИ