Пользователи не могут установить Windows 10 1909 из-за даты в BIOS

Пользователи не могут установить Windows 10 1909 из-за даты в BIOS

Пользователи не могут установить Windows 10 1909 из-за даты в BIOS

Ряд пользователей Windows 10 столкнулся со странным багом при попытке установить последний релиз операционной системы. Сообщается, что проблема возникает из-за BIOS, дата которого установлена на 19 января 3001 года или позже. Затронуты материнские платы от AMD и Intel.

ИТ-специалист Кэри Хольцман, ведущий собственный канал на YouTube, поделился своим мнением относительно бага:

«Похоже на то, что BIOS (на платах AMD или Intel) позволяет установить 19-1-3001 и более позднюю дату. В этом случае Windows 10 1909 не может завершить установку, зависнув на второй перезагрузке».

«Более того, если попробуете поменять дату в BIOS, а потом перезагрузите компьютер, рассчитывая обойти проблему, — у вас ничего не получится. Windows 10 опять зависнет, а дата снова сбросится на условное 19 января 3001 года».

Баг настолько устойчивый, что его не получится устранить никакой сменой аппаратных характеристик системы. Известно, что с проблемой столкнулись пользователи материнских плат Gigabyte H370 HD3 (для процессоров Intel) и Gigabyte x570 Aorus Elite (для процессоров AMD).

Чтобы нормально установить последнюю версию Windows 10 на свой компьютер, вам придётся первым делом разобраться с датой BIOS, после чего очистить все разделы вашего диска SSD/HDD. Только потом можно устанавливать Windows 10 1909.

Также полезно будет ознакомиться с видео Хольцмана, в котором он подробно описывает баг и рассказывает, что с ним делать:

Claude освободил 700 ГБ, удалив домашнюю папку разработчика

Разработчик Себастьен Гиймо поручил ИИ-агенту Claude написать скрипт для очистки временных файлов. Бот справился слишком эффективно: удалил домашний каталог пользователя вместе с 700 ГБ данных и результатами недельной работы, но предусмотрительно оставил папку /tmp, ради которой всё и затевалось.

Гиймо регулярно запускает ИИ-агентов, которые оставляют после себя множество временных файлов.

Он попросил модель Claude Fable создать отдельную песочницу для каждого агента в /tmp и очищать её после завершения работы, не затрагивая используемые данные.

Первая версия скрипта показалась разработчику слишком сложной. Из-за наличия команд безвозвратного удаления Claude запустил дополнительную проверку безопасности. Система Anthropic сочла задачу рискованной и автоматически понизила модель сначала до Opus 5, а затем до Opus 4.8.


Новая модель написала тест, который сравнивал цели удаления с /tmp и домашним каталогом пользователя. Обе директории были правильно признаны опасными. А затем начался этап очистки тестовых данных, и Claude повторно использовал ту же переменную, в которой находился путь к домашней папке.

Гиймо остановил процесс, но слишком поздно: агент успел удалить 700 ГБ. Большую часть информации разработчик восстановил из Git, конфигурации Nix, журналов сессий и других источников. Однако недельная работа всё же пострадала.

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

RSS: Новости на портале Anti-Malware.ru