Жесть какая. На форуме леновы, кстати, пишут, дескать, проблема в том что какой-то компонент ведра в новой убунте просто убивает секцию NVRAM многократными перезаписями. Хотя видел так-же мнение, что NVRAM просто лочится на запись. Так или иначе, похоже что единственный способ - это перепайка микросхемы бивиса с перепрошивкой содержимого из старой микросхемы с убитым ресурсом.

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

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

есть, есть.

А не в курсе, какой вообще ресурс перезаписи у современных микросхем с бивисом (ну то есть с UEFI) ? Ведь дистры линуксов сейчас предлагают обновления ядер чуть-ли даже не чаще чем официальное ведро обновляется. И при каждом обновлении оно тыркает граб с efibootmgr, который вполне себе может по-идее исчерпать ресурс записи (если он очень небольшой) в NVRAM который выделяется как область где-то в микросхеме бивиса.

какой-то компонент ведра в новой убунте просто убивает секцию NVRAM многократными перезаписями

А можно ссыль на обсуждение?

Выглядит неправдоподобно. У биосов обычно используют небольшую nor-память на десятки мегабайт. А у неё миллионы циклов стирания и само стирание весьма медленное.

А можно ссыль на обсуждение?

Вот от этого сообщения и дальше: тыц

Выглядит неправдоподобно. У биосов обычно используют небольшую nor-память на десятки мегабайт. А у неё миллионы циклов стирания и само стирание весьма медленное.

Мне тоже так казалось всегда. Между тем, часть настроек UEFI, как я понимаю, всё-таки хранится именно на флешке, а не в CMOS'е. В частности, настройки загрузки (возможно, я и не прав, не углублялся настолько, ибо ненужно пока было знать такие детали для работы).

На этой обоссанской серии ленов бивис и так через день дохнет, лол. Сколько уж я их перешил.

Сами микрухи дохнут редко, а вот их содержимое весьма часто.

http://www.cyberforum.ru/notebook-repair/thread1697544.html

А чем эта серия отличается скажем от ideapad 110s? А то у меня как раз он, и там как раз убунта 17.10, пока живой, мне не обновлять ядро?

Не знаю с чем это конкретно связано, просто по опыту говорю, пруфы выше. На твоем буке с таким не сталкивался, но биос обнови на всякий случай.

Не сохраняются изменения настроек EFI.

Благодарю за новость. Чёт я приуныл :(

Походу просто ленова слишком копризна вот и вскрылся косяк на убунте. При этом обычные компы от убунты не страдают.

какой-то компонент ведра в новой убунте просто убивает секцию NVRAM многократными перезаписями

Бред, nvram - это не nand, а память, питаящаяся батарейкой. Убить её перезаписью невозможно.

Lenovo Z50-70

Такая машинка есть, бага не наблюдал.

Радость то какая, все бюджетные и ходовые линейки ноутов.
Блин, а я то без ноута остался. Страшно подумать что надо будет снова выбирать, когда надо будет 8-(

офигел и пошел шариться на Делл 8-(

Ничего страшного нет. Всё что надо тут

https://www.apple.com/ru/mac/

Во, Пони в теме.

Если бы не Луис Россман, я бы был уверенный!
Но вот с другой стороны... кусок крепкого люминию и вменяемое железо по производительности, то как бы да...

Ubuntu снова убивает Леновы

/fixed

При чем тут убунта если драйвер в ядре? Очевидно, что линукс виноват в проблеме.

Очевидно, что линукс виноват в проблеме.

Пока это очевидно только вендотроллям.

Формально он прав. МБ_Про 13" в минималке стоит 1300, новое яйцо тулит бюджетные аналоги за 800++

новое яйцо тулит бюджетные аналоги за 800++

Не знаю о каких яйцах речь, но ноуты xiaomi слиты с ябла.

https://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100006740%20600004341%204814%20600451155%20600515142%20600555621%20601303722%20601283907%20600003982%20601283905%20600003988&IsNodeId=1&bop=And&Order=PRICE&PageSize=36

Как-то так, если откроется ссылка нормально

Шерето

ресурс перезаписи у современных микросхем с бивисом (ну то есть с UEFI)

ресурс

таки я всё правильно сделал, что вернулся на MBR и LILO

То есть, эти долбозвоны вместо записи загрузчика в UEFI, который будет уже ядро грузить, постоянно насилуют NVRAM?

Просто используй MBR, если есть возможность.

Выбор будет очевиден: ThinkPad X220 с вшиванием туда Coreboot.

Как и с 12309 долбоклюи намешали всего вместе...

пропадает возможность изменения настроек

Всмысле? В bios uEFI перестает пускать? В чем поконкретнее выражается трагедия?

и загрузки с USB

А это не баг а фича uEFI. Курите маны.

Нет, я хочу современный ноутбук, у которого вытаскивается процессор, есть 2 слота под память и отдельно втыкается и вытыкается м.2 ссд и как вишенка на тортике - есть САТА разъем для традиционного механического или твердотельного накопителя. 2,5"

а денег я хочу заплатить за такое удовольствие не более 400долл, как в 2010 году.
за два ведра и два гига, остальное сам доставлю.
%-)

только теперь за схожую конфигурацию просят уже 500-600долл.

ubuntu 17.10

Они туда ещё какой-то глючный Grub и os-prober засунули, который гоняет впустую grub-mount около 10 минут и нагружает CPU на 100%.

Сталкивался кто?

Бред, nvram - это не nand, а память, питаящаяся батарейкой. Убить её перезаписью невозможно.

Вы не правы. NVRAM - это только общее название, на физическом уровне оно может быть реализовано и как SRAM с батарейкой, и как хранилище на флеш памяти.

Вот как это работает в UEFI : https://habrahabr.ru/post/281242

В данном конкретном случае, насколько я понял, NVRAM убивает тот самый модуль intel-spi-*

А вообще, у всех современных дистрибутивов загрузка через UEFI организовывается следующим образом: 1. Нужные опции загрузки прописываются в меню загрузчика (GRUB, например). 2. Загрузчик (GRUB) прописывается как первый пункт меню загрузки в UEFI - модифицируя тем самым содержимое NVRAM и снижая ресурс микросхемы флеш-памяти где этот самый NVRAM сейчас и лежит.

При обновлении ведра, во время выполнения скриптов установки - как правило, обновляется меню загрузчика, и, в том числе может дергается efibootmgr для установки дефолтного загрузчика в UEFI.

Если-бы я делал свой дистрибутив (а я что-то такое уже делал, когда организовывал безопасную загрузку со своими ключами SecureBoot на производственном ПК), то я не стал-бы дёргать efibootmgr на запись загрузчика, если дефолтный пункт меню не изменился. Между тем, когда-то давно в паре дистрибутивов я наблюдал такую картину - когда при любом обновлении ведра, дергался efibootmgr с параметрами для установки дефолтного загрузчика. Не могу однозначно сказать, дергается-ли efibootmgr вообще на запись в современной убунте при каждом обновлении ведра, но в очень многих дистрах он дергается при обновлении.

С тех времён, я вообще на всякий случай использую свой GRUB установленный вместе с shim'ом вручную в «портативном» режиме (bootx64.efi), а в самом дистрибутиве никакой загрузчик и efibootmgr не устанавливаю вообще. Не только потому что боюсь износа микросхемы, но и потому что насмотрелся багов с efibootmgr, когда он вообще напрочь убивал загрузку.

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

Ого, давно я не слышал про убийство Бивиса софтом.

вшиванием туда Coreboot

Libreboot.

Интересно, не знал.

Эхх, 2k17 на дворе, а я с этими вашими UEFI-проблемами до сих пор даже не сталкивался.

Эт чё, батарейка сядет — слетит загрузчик? Ну и дерьмо.

Эт чё, батарейка сядет — слетит загрузчик?

Как раз наоборот, в случае с UEFI - не слетит. Ну то есть - не сам загрузчик а настройка порядка загрузки UEFI, загрузчик-то лежит на EFI-разделе жесткого диска.

Мало того, на некоторых материнках эта настройка не слетит даже в случае, когда она намертво запорота efibootmgr'ом (на некоторых материнках такое бывает) и вы пытаетесь всё сбросить в дефолтное состояние перемычкой «clear CMOS» (которая на самом деле в случае с UEFI, собственно, к CMOS'у не имеет особого отношения).

это у тебя вот так будет. Не сохраняются изменения настроек EFI.

Это тред про сабжевую проблему, какое отношение несохранение новых недефолтных настроек имеет к утрате старых недефолтных?