Исходное сообщение
"Debian 12 перешёл на стадию мягкой заморозки перед релизом " Отправлено Unknown, 20-Фев-23 21:16
Есть подозрение, что с этим 8 поколением все не слава богу. Моя история: есть Intel Nuc на i7-8559U. Работал "без единого разрыва" года 4 на Debian 10 (а заодно, на хакинтоше и win10). Обновления все ставились регулярно, в том числе и на BIOS. "Ничто не предвещало". Надо заметить, что паттерн использования у меня своеобразный - я комп вообще не выключаю, так что аптайм у него неделями. После выхода 11 Debian было некогда обновиться и ставил обновления сразу на BIOS и систему где-то в начале осени 21 года. И начались приключения - спустя какое-то время начал замечать, что система зависает насмерть. Грешил на ядро 5.10, перешел на Testing - тот же результат, на 5.16 вообще ядро не грузилось. Заводил багрепорты, но толку ноль. Спустя некоторое время решился поставить рядом 10 Debian, т.к. работать было невозможно - система зависала непредсказуемо. Но выяснилось, что и старый Debian работает тоже не очень стабильно - зависает, хотя и несколько позже. Тут стало приходить понимание, что дело явно не в ядре. Из того, что на экран зависающие ядра вообще ничего не выводили, пришел к выводу, что дело где-то в самом начале процесса загрузки ядра. По dmesg посмотрел первые строки нормально загрузки - а там обновление микрокода процессора. Снес пакет intel-microcode - и все заработало как надо. Но, лишь на какое-то время. Дебиан тестинг стабильно дообновлялся до ядра 6.0 - проблем не было. Но как только приехало 6.1 - снова начались проблемы с загрузкой. На экране появлялась надпись на русском, что не достаточно памяти для загрузки и после этого ядро падало в панику. Понятно, что ядро на русском писать не будет - значит grub2. Гугл находит тикет https://bugs.launchpad.net/oem-priority/+bug/1842320, краткая суть которого, что UEFI так отдает раскладку памяти, что grub2 как-то не так ее использует и в результате не может выбрать правильный кусок свободного места чтобы положить ядро и initrd. Т.е. на 6.0 того куска хватало, а на 6.1 уже не хватает. Актуально на разрешениях 4к, на других люди кажется не сталкивались. Лечится патчами, но быстро можно поправить, если руками указать grub2 указать использование разрешения 800x600. Сделал - действительно все заработало как надо. P.S. а с обновлением микрокода, похоже, проблему не решить. Потому что на последнем свежем BIOS через какое-то время зависает все: linux, win10 и хакинтош. Причем, если на первые 2 можно было бы грешить на все тот же баг с grub2, то хакинтош грузился своим загрузчиком, но стабильной работы не получилось. Пришлось BIOS откатить на несколько версий.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, [email protected] (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Есть подозрение, что с этим 8 поколением все не слава богу. Моя > история: есть Intel Nuc на i7-8559U. Работал "без единого разрыва" года > 4 на Debian 10 (а заодно, на хакинтоше и win10). Обновления > все ставились регулярно, в том числе и на BIOS. "Ничто не > предвещало". Надо заметить, что паттерн использования у меня своеобразный - я > комп вообще не выключаю, так что аптайм у него неделями. После > выхода 11 Debian было некогда обновиться и ставил обновления сразу на > BIOS и систему где-то в начале осени 21 года. И начались > приключения - спустя какое-то время начал замечать, что система зависает насмерть. > Грешил на ядро 5.10, перешел на Testing - тот же результат, > на 5.16 вообще ядро не грузилось. Заводил багрепорты, но толку ноль. > Спустя некоторое время решился поставить рядом 10 Debian, т.к. работать было > невозможно - система зависала непредсказуемо. Но выяснилось, что и старый Debian > работает тоже не очень стабильно - зависает, хотя и несколько позже. > Тут стало приходить понимание, что дело явно не в ядре. Из > того, что на экран зависающие ядра вообще ничего не выводили, пришел > к выводу, что дело где-то в самом начале процесса загрузки ядра. > По dmesg посмотрел первые строки нормально загрузки - а там обновление > микрокода процессора. Снес пакет intel-microcode - и все заработало как надо. > Но, лишь на какое-то время. Дебиан тестинг стабильно дообновлялся до ядра > 6.0 - проблем не было. Но как только приехало 6.1 - > снова начались проблемы с загрузкой. На экране появлялась надпись на русском, > что не достаточно памяти для загрузки и после этого ядро падало > в панику. Понятно, что ядро на русском писать не будет - > значит grub2. Гугл находит тикет https://bugs.launchpad.net/oem-priority/+bug/1842320, > краткая суть которого, что UEFI так отдает раскладку памяти, что grub2 > как-то не так ее использует и в результате не может выбрать > правильный кусок свободного места чтобы положить ядро и initrd. Т.е. на > 6.0 того куска хватало, а на 6.1 уже не хватает. Актуально > на разрешениях 4к, на других люди кажется не сталкивались. Лечится патчами, > но быстро можно поправить, если руками указать grub2 указать использование разрешения > 800x600. Сделал - действительно все заработало как надо. > P.S. а с обновлением микрокода, похоже, проблему не решить. Потому что на > последнем свежем BIOS через какое-то время зависает все: linux, win10 и > хакинтош. Причем, если на первые 2 можно было бы грешить на > все тот же баг с grub2, то хакинтош грузился своим загрузчиком, > но стабильной работы не получилось. Пришлось BIOS откатить на несколько версий.
	Введите код, изображенный на картинке: