Created attachment 10889 [details] Экран установки Образования 10 Обнаружил при установке Образование 10 Насчет нового ядра, подсказали в чате, все модули ядра Virtualbo xзагружены Это и в p10 и в текущкм Сизифе # uname -r 5.15.44-un-def-alt1 t1 # lsmod | grep vbox vboxnetadp 28672 0 vboxnetflt 32768 0 vboxdrv 532480 2 vboxnetadp,vboxnetflt vboxvideo 32768 0 drm_vram_helper 24576 1 vboxvideo vboxsf 40960 0 vboxguest 45056 1 vboxsf drm_ttm_helper 16384 4 drm_vram_helper,vboxvideo,amdgpu,radeon drm_kms_helper 319488 4 drm_vram_helper,vboxvideo,amdgpu,radeon drm 638976 26 gpu_sched,drm_kms_helper,drm_vram_helper,vboxvideo,amdgpu,radeon,drm_ttm_helper,ttm PS md5sum образа совпадает, с него недавно ставил. PPS Сейчас ещё ядро std-def попробую
(Ответ для ruslandh на комментарий #0) > Создано вложение 10889 [details] [подробности] > Экран установки Образования 10 > > Обнаружил при установке Образование 10 > > Насчет нового ядра, подсказали в чате, все модули ядра Virtualbo xзагружены > Это и в p10 и в текущкм Сизифе > > # uname -r > 5.15.44-un-def-alt1 > > t1 > > # lsmod | grep vbox > vboxnetadp 28672 0 > vboxnetflt 32768 0 > vboxdrv 532480 2 vboxnetadp,vboxnetflt > vboxvideo 32768 0 > drm_vram_helper 24576 1 vboxvideo > vboxsf 40960 0 > vboxguest 45056 1 vboxsf > drm_ttm_helper 16384 4 drm_vram_helper,vboxvideo,amdgpu,radeon > drm_kms_helper 319488 4 drm_vram_helper,vboxvideo,amdgpu,radeon > drm 638976 26 > gpu_sched,drm_kms_helper,drm_vram_helper,vboxvideo,amdgpu,radeon, > drm_ttm_helper,ttm > > > PS md5sum образа совпадает, с него недавно ставил. > > PPS Сейчас ещё ядро std-def попробую
В Сизифе $ uname -r 5.15.44-std-def-alt1 то-же не работает.
А ядро std-def в p10?
В P10 std-def всё нормально, на un-def та-же проблема, как и в Сизифе $ uname -r 5.10.118-std-def-alt1
$ uname -r 5.15.45-un-def-alt1 По-прежнему выпадает
Сизиф $ uname -r 5.17.13-un-def-alt1 выпадает
Created attachment 10890 [details] Ролик места выпадения Базовая система установилась, момент перехода к установки остальных пакетв
По Сизифу: $ uname -r 5.15.45-std-def-alt1 Тоже выпадает. Проверил на всех установленных ядрах у меня $ rpm -qa | grep kernel-image kernel-image-std-def-5.15.45-alt1.x86_64 kernel-image-std-def-5.15.44-alt1.x86_64 kernel-image-un-def-5.17.13-alt1.x86_64 kernel-image-un-def-5.17.12-alt1.x86_64 Везде выпадает. Некстати недавно удалил все более старые ядра, что-бы проверить.
В p10 $ uname -r 5.15.43-un-def-alt1 Ошибки тоже нет
Итого по p10 ядрам : $ rpm -qa | grep kernel-image kernel-image-un-def-5.15.45-alt1.x86_64 kernel-image-std-def-5.10.118-alt1.x86_64 kernel-image-un-def-5.15.43-alt1.x86_64 kernel-image-un-def-5.15.44-alt1.x86_64 Ошибка воспроизводится на : kernel-image-un-def-5.15.44-alt1.x86_64 kernel-image-un-def-5.15.45-alt1.x86_64 Ошибки нет на: kernel-image-std-def-5.10.118-alt1.x86_64 kernel-image-un-def-5.15.43-alt1.x86_64 Регрессия произошла между kernel-image-un-def-5.15.43-alt1.x86_64 и kernel-image-un-def-5.15.44-alt1.x86_64
Воспроизвёл проблему. iso стартеркита engineering лежал на HDD. Переместил iso на SSD и тогда установилось нормально. Видимо, apt ждёт слишком мало времени и на медленных накопителях такая проблема происходит. Скорее всего эту проблему можно воспроизвести на медленной флэшке. Конкретно virtualbox стал медленнее работать с HDD, видимо. Ну и в инсталяторе если сделать apt-get update будет ругань на то, что Cache-Limit (33554432) is below the recommended default value (201326592). Т.е. в инсталяторе Cache-Limit слишком маленький. Он выставлен в /etc/apt/apt-conf.d/installer-cache-limit.conf Это пакет installer-common-stage2. Руслан, поменяй на рекомендованный и попробуй, будет ли проблема воспроизводиться?
В installer APT::Cache-Limit "$((32*1024*1024))"; был добавлен glebfm@ в 2015 году: https://git.altlinux.org/gears/i/installer.git?p=installer.git;a=commitdiff;h=fa63948a90436ec24c757c4282a5b642bdb04025 Видимо, в связи с увеличением лимита в 2 раза тогда же в apt: https://git.altlinux.org/gears/a/apt.git?p=apt.git;a=commitdiff;h=abf6d39f75266c153fbfcb2c0f38131f05b67bd4 Чтобы было в инсталяторе, как раньше. Вопрос к Глебу и другим знающим: почему этот параметр не надо делать большим в инсталяторе? Какие есть противопоказания?
нужно восстановить патч для apt с динамической аллокацией памяти и тогда этот параметр не будет нужен совсем.
(In reply to Антон Мидюков from comment #12) > В installer APT::Cache-Limit "$((32*1024*1024))"; был добавлен glebfm@ в > 2015 году: > > https://git.altlinux.org/gears/i/installer.git?p=installer.git;a=commitdiff; > h=fa63948a90436ec24c757c4282a5b642bdb04025 > > Видимо, в связи с увеличением лимита в 2 раза тогда же в apt: > https://git.altlinux.org/gears/a/apt.git?p=apt.git;a=commitdiff; > h=abf6d39f75266c153fbfcb2c0f38131f05b67bd4 С тех пор мы в apt ещё увеличили объём выделяемой памяти. Но не в инсталляторе. > Чтобы было в инсталяторе, как раньше. > Вопрос к Глебу и другим знающим: почему этот параметр не надо делать большим > в инсталяторе? Какие есть противопоказания? Наверное, просто их опасений, что на дохленькой машине инсталляция не пойдёт. Но если есть у других более подробные обоснования, чем моё предположение, то пожалуйста высказывайте. Я сам с таким сталкивался давно на очень старой i586-машине, что с трудом инсталляция по памяти проходила. (Согласен про патч про динамическую память. Это держу в голове, тоже займусь.)
(In reply to Антон Мидюков from comment #11) > Воспроизвёл проблему. iso стартеркита engineering лежал на HDD. Переместил > iso на SSD и тогда установилось нормально. Видимо, apt ждёт слишком мало > времени и на медленных накопителях такая проблема происходит. Скорее всего > эту проблему можно воспроизвести на медленной флэшке. > > Конкретно virtualbox стал медленнее работать с HDD, видимо. > > Ну и в инсталяторе если сделать apt-get update будет ругань на то, что > Cache-Limit (33554432) is below the recommended default value (201326592). > Т.е. в инсталяторе Cache-Limit слишком маленький. > Он выставлен в /etc/apt/apt-conf.d/installer-cache-limit.conf > Это пакет installer-common-stage2. > > Руслан, поменяй на рекомендованный и попробуй, будет ли проблема > воспроизводиться? Скорее всего это не имеет отношения к делу. Потому что это просто warning, а не ошибка. Т.е. если бы выделенной памяти реально не хватило, была бы другая настоящая ошибка. Можно не торопиться менять это значение вслед за основным пакетом apt -- главное, чтобы в процессе установки хватало выделенной памяти на кеш всех пакетов, которые видны в момент установки. (И не было ошибки.) Если увеличить поспешно, то потеряем возможность прохождения установки на машинах с малым объёмом памяти.
checksum mismatch может быть как-то связано с недавним усилением проверки cheksums в apt. Я ещё повнимательнее посмотрю на этот случай, может ли это бытьт связано.
(In reply to Антон Мидюков from comment #12) > Чтобы было в инсталяторе, как раньше. Не как раньше, а гораздо-гораздо меньше. Индексы пакетов на диске обычно совсем маленькие, там даже от 32-х мегабайтах речи не идёт. > Вопрос к Глебу и другим знающим: почему этот параметр не надо делать большим > в инсталяторе? Какие есть противопоказания? Это просто ни на что не повлияет и не связано с багом, как и сказал Ваня.
(In reply to Ivan Zakharyaschev from comment #16) > checksum mismatch может быть как-то связано с недавним усилением проверки > cheksums в apt. Я ещё повнимательнее посмотрю на этот случай, может ли это > бытьт связано. Если установить в true опции Debug::pkgAcquire::Auth и Acquire::Verbose, то мы должны увидеть больше подробностей.
(Ответ для Gleb F-Malinovskiy на комментарий #17) > (In reply to Антон Мидюков from comment #12) > > Вопрос к Глебу и другим знающим: почему этот параметр не надо делать большим > > в инсталяторе? Какие есть противопоказания? > > Это просто ни на что не повлияет и не связано с багом, как и сказал Ваня. Понятно. Большее число попыток установки показало, что это было совпадение. Всё-таки иногда и так устанавливается. Но когда iso на SSD, установка проходит успешно явно чаще (не получилось проблему воспроизвести).
Created attachment 10892 [details] Упала установка (с отладкой) Добавил опции в apt.conf: Debug::pkgAcquire::Auth true; Acquire::Verbose true; Добавились сообщения вида BLAKE2b mismath: <хэш>
Created attachment 10893 [details] Ошибки чтения в dmesg Куча ошибок чтения из /dev/sr0. Т.е. действительно прочитать не может с диска. Проверил установку на реальный компьютер с очень медленной флэшки (с логотипом "Базальт"). Долго, но успешно.
(In reply to Антон Мидюков from comment #20) > Created attachment 10892 [details] > Упала установка (с отладкой) > > Добавил опции в apt.conf: > Debug::pkgAcquire::Auth true; > Acquire::Verbose true; > > Добавились сообщения вида > BLAKE2b mismath: <хэш> Там справо ещё должно быть продолжение. Не попало на снимок. Выводится так: cerr << ChkType << " mismatch: " << ExpectHash << "!=" << AcqHash << endl; Так что по этому скриншоту мы не видим какой реально хеш оно насчитало. Только ожидаемый попал на снимок.
Created attachment 10894 [details] лог установки пакетов
(In reply to Антон Мидюков from comment #23) > Created attachment 10894 [details] > лог установки пакетов Спасибо. Тут видно, что каждый раз какое-то новое значение хеша подсчитывается для полученного реально файла. (Т.е. это не какой-то один и тот же пустой каждый раз.) И мы пришли к выводу, что это ошибки чтения с cdrom, никак не связанные с apt, да?
(Ответ для Ivan Zakharyaschev на комментарий #24) > (In reply to Антон Мидюков from comment #23) > > Created attachment 10894 [details] [подробности] [details] > > лог установки пакетов > > Спасибо. Тут видно, что каждый раз какое-то новое значение хеша > подсчитывается для полученного реально файла. (Т.е. это не какой-то один и > тот же пустой каждый раз.) > > И мы пришли к выводу, что это ошибки чтения с cdrom, никак не связанные с > apt, да? Сообщения из dmesg на это намекают.
Было бы неплохо научиться проверять пакеты перед установкой.
(In reply to Anton Farygin from comment #26) > Было бы неплохо научиться проверять пакеты перед установкой. Эээ. Ну в общем-то это и произошло, разве нет? :)
нет, я имею в виду с визуальным отображением ошибки и понятной пользователю диагностикой. Например, в виде шага инсталятора "проверка носителя"
У меня после обновления системы развалилась виртуалка с 10й виндой - возможно как-то связано. После нескольких перезагрузок с попытками восстановится ушла в себя. Тоже очень похоже на ошибки дисковых операций. Возможно и не в тему.
Зависло, какие команды кроме dmesg выполнить ?
Created attachment 10895 [details] Заархивированный /tmp Заархивированный /tmp в внутри устанавливаемой машины , плюс накидал туда файликов руками
Created attachment 10896 [details] Выдача команды dmesg
Created attachment 10897 [details] Вид падения Добавил все параметры, что Антон предлагал и что тут прочитал. В этот раз упала по другому. Машина ещё работает, если что, могу ещё что-нибудь через флешку скинуть. В некоторых файлах видна флешка, на неёё внимание не обращайте, я её позже примонтировал
Короче, я эту виртуалку усыпил в этом состоянии, если что, можно ещё каку-нибуди информацию добавить.
Как я понял обсуждение - ошибка чтения с диска sr0. Все остальные ошибки - иррелевантны.
Диск смонтирован, файлы видны, можно попробовать их скопировать.
Вот эти строчки в dmesg смущают [ 555.289677] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) [ 558.301255] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null)
1. не надо ничего менять в настройках apt. 2. нужно попробовать переместить виртуальные накопители на SSD. И попробовать. Поможет или нет. Мне помогает. Есть такая возможность?
SD диск не помог https://disk.yandex.ru/i/sdaLVr0rG6oB5w Машину усыпил
Created attachment 10898 [details] Конц строки, который на Video не виден Конц строки, который на Video не виден
Created attachment 10899 [details] Вот такое второй раз вижу Второй раз такое вижу, при попытке начала установки идёт непонятная перезагрузка
(Ответ для ruslandh на комментарий #41) > Создано вложение 10899 [details] [подробности] > Вот такое второй раз вижу > > Второй раз такое вижу, при попытке начала установки идёт непонятная > перезагрузка Я тоже вчера такое ловил. Пробую ядро 5.15.43-un-def из архива за 29 мая, всё хорошо пока. Я именно на этом ядре все стартеркиты 20220605 прогонял и всё было хорошо. А обновил ядро уже позже. Так что скорее всего регрессия между 5.15.43 и 5.15.44
(Ответ для Антон Мидюков на комментарий #42) > (Ответ для ruslandh на комментарий #41) > > Создано вложение 10899 [details] [подробности] > > Вот такое второй раз вижу > > > > Второй раз такое вижу, при попытке начала установки идёт непонятная > > перезагрузка > > Я тоже вчера такое ловил. > > Пробую ядро 5.15.43-un-def из архива за 29 мая, всё хорошо пока. Я именно на > этом ядре все стартеркиты 20220605 прогонял и всё было хорошо. А обновил > ядро уже позже. Так что скорее всего регрессия между 5.15.43 и 5.15.44 5.15.43-std-def конечно же.
https://disk.yandex.ru/d/G9bvYYE3yU8NYQ На новых ядрах не исправилось проверил: kernel-image-std-def-5.15.46-alt1.x86_64 kernel-image-un-def-5.17.14-alt1.x86_64 Пернос на SD даёт эффект (меньше сообщений о несовпавших суммах файлов), но полностью не лечит
Поскольку в p10 регрессия поймана на ветке un-def, а в Сизифе на std-def, наводят на мысли "странное" совпадение, что в обеих случах регрессия между kernel-image-*-def-5.15.43-alt1.x86_64 и kernel-image-*-def-5.15.44-alt1.x86_64 Но я думаю, ядерщикам легче подсказать с чем это может быть связано. У меня две версии - проблема в самом ядре - проблема в сборке модулей virtualbox
(In reply to ruslandh from comment #32) > Created attachment 10896 [details] > Выдача команды dmesg Из нового, имеющего отношение к apt: [ 1179.895946] traps: apt-get[3442] general protection fault ip:7fb28b312b09 sp:7ffcfc301ab0 error:0 in libapt-pkg-libc6.9-6.so.10.1.0[7fb28b2a6000+8f000]
(In reply to ruslandh from comment #33) > Created attachment 10897 [details] > Вид падения > > Добавил все параметры, что Антон предлагал и что тут прочитал. > В этот раз упала по другому. > Машина ещё работает, если что, могу ещё что-нибудь через флешку скинуть. > > В некоторых файлах видна флешка, на неёё внимание не обращайте, я её позже > примонтировал То, что здесь видно -- это другая ошибка apt (и больше ничего на скриншоте нет). Пишу текстом для дуобства дальнейшего анализа. E: The package lists or status file could not be parsed or opened. E: Unable to truncate to 18446744073709551615 Последнее это из функции: bool FileFd::Truncate(unsigned long To) { if (ftruncate(iFd,To) != 0) { Flags |= Fail; return _error->Error("Unable to truncate to %lu",To); } return true; } вызванной через цепочку других функций из (по первому сообщению): std::unique_ptr<MMap> pkgMakeStatusCache(pkgSourceList &List,OpProgress &Progress, bool AllowMem); std::unique_ptr<MMap> pkgCacheFile::MakeMap(OpProgress &Progress) { ... const bool AllowMem = (!WithLock || _config->FindB("Debug::NoLocking",false)); std::unique_ptr<MMap> Map = pkgMakeStatusCache(*SrcList,Progress,AllowMem); Progress.Done(); if (Map == nullptr) { _error->Error(_("The package lists or status file could not be parsed or opened.")); return nullptr; } ... } Указанный размер -- это 64-битное -1: $ printf '%x\n' 18446744073709551615 ffffffffffffffff $ printf '%x\n' -1 ffffffffffffffff Посмотрю ещё по коду, что послужило источником этой ошибки.
В этой схеме - где участвуют все эти версии ядер? Где выводятся ошибки чтения диска? Где general protection fault? В виртуализации есть понятия гость и хост - они ни разу не были упомянуты.
(Ответ для Vitaly Chikunov на комментарий #48) > В этой схеме - где участвуют все эти версии ядер? Где выводятся ошибки > чтения диска? Где general protection fault? В виртуализации есть понятия > гость и хост - они ни разу не были упомянуты. На госте при возникновении проблемы в dmesg много ошибок чтения с sr0.
(Ответ для Антон Мидюков на комментарий #49) > (Ответ для Vitaly Chikunov на комментарий #48) > > В этой схеме - где участвуют все эти версии ядер? Где выводятся ошибки > > чтения диска? Где general protection fault? В виртуализации есть понятия > > гость и хост - они ни разу не были упомянуты. > > На госте при возникновении проблемы в dmesg много ошибок чтения с sr0. В эксперименте меняется только ядро хоста, виртуалка та же. Когда на хосте ядро 5.15.43 установка проходит успешно. Когда 5.15.44 и новее, то установка прерывается с ошибками.
-1 скорее всего происходит из неправильного задания в конфигурации у Руслана значения APT::Cache-Limit, которое попадает в RequestedWorkSpace ниже в mmap.cc: auto const EndOfFile = Fd->Size(); /* The backing file must be made at least as big as the requested workspace that we are going to use in the course of work. */ if (EndOfFile < RequestedWorkSpace) { if (!Fd->Truncate(RequestedWorkSpace)) return; }
Так что пока единственное, что мы наблюдаем, это скорее всего ошибка чтения файлов, а не проблемы в apt. Наверное, они плохо читаются и вне apt.
(Ответ для Ivan Zakharyaschev на комментарий #52) > Так что пока единственное, что мы наблюдаем, это скорее всего ошибка чтения > файлов, а не проблемы в apt. Наверное, они плохо читаются и вне apt. Но почему-то начиная с 5.15.44, так?
(In reply to AEN from comment #53) > (Ответ для Ivan Zakharyaschev на комментарий #52) > > Так что пока единственное, что мы наблюдаем, это скорее всего ошибка чтения > > файлов, а не проблемы в apt. Наверное, они плохо читаются и вне apt. > > Но почему-то начиная с 5.15.44, так? Пишут про эту версию ядра на хосте, да: (In reply to Антон Мидюков from comment #50) > В эксперименте меняется только ядро хоста, виртуалка та же. Когда на хосте > ядро 5.15.43 установка проходит успешно. Когда 5.15.44 и новее, то установка > прерывается с ошибками.
А на госте вообще неважно какое ядро ?
(Ответ для Anton Farygin на комментарий #55) > А на госте вообще неважно какое ядро ? Неважно.
ну тогда не надо даже и думать - это проблема virtualbox. Было бы неплохо, ради интереса, проверить откатив его (virtualbox) на более старую версию.
(Ответ для Anton Farygin на комментарий #57) > ну тогда не надо даже и думать - это проблема virtualbox. Было бы неплохо, > ради интереса, проверить откатив его (virtualbox) на более старую версию. Сама VirtualBox , это маловероятно, так-как именно этой версией пользуюсь уже достаточно давно. Смущает ещё один факт, у официальной версии на новых ядрах перестали собираться её модули ядра с новыми ядрами (есть у меня один комп с такой версией ядра), Возможно с эти с связано (в смысле модули "не так" cобираются) но конечно это не факт, а только гипотеза.
В смысле с такой версией Виртуалбокс ;-)
(Ответ для Ivan Zakharyaschev на комментарий #47) > (In reply to ruslandh from comment #33) > > Created attachment 10897 [details] [подробности] [details] > > Вид падения > > > > Добавил все параметры, что Антон предлагал и что тут прочитал. > > В этот раз упала по другому. > > Машина ещё работает, если что, могу ещё что-нибудь через флешку скинуть. > > > > В некоторых файлах видна флешка, на неёё внимание не обращайте, я её позже > > примонтировал > > То, что здесь видно -- это другая ошибка apt (и больше ничего на скриншоте > нет). > Пишу текстом для дуобства дальнейшего анализа. > > E: The package lists or status file could not be parsed or opened. > E: Unable to truncate to 18446744073709551615 > > Последнее это из функции: > > bool FileFd::Truncate(unsigned long To) > { > if (ftruncate(iFd,To) != 0) > { > Flags |= Fail; > return _error->Error("Unable to truncate to %lu",To); > } > > return true; > } > > вызванной через цепочку других функций из (по первому сообщению): > > std::unique_ptr<MMap> pkgMakeStatusCache(pkgSourceList &List,OpProgress > &Progress, > bool AllowMem); > > std::unique_ptr<MMap> pkgCacheFile::MakeMap(OpProgress &Progress) > { > ... > > const bool AllowMem = (!WithLock > || _config->FindB("Debug::NoLocking",false)); > std::unique_ptr<MMap> Map = > pkgMakeStatusCache(*SrcList,Progress,AllowMem); > Progress.Done(); > if (Map == nullptr) > { > _error->Error(_("The package lists or status file could not be parsed > or opened.")); > return nullptr; > } > > ... > > } > > Указанный размер -- это 64-битное -1: > > $ printf '%x\n' 18446744073709551615 > ffffffffffffffff > $ printf '%x\n' -1 > ffffffffffffffff > > Посмотрю ещё по коду, что послужило источником этой ошибки. А вот тут интересно, в файле /etc/apt/apt-conf.d/installer-cache-limit.conf совсем не то число, которое я записал. Как будто оно размножилось. Сейчас приложу картину (буфер обмена вне графики не работает).
Created attachment 10904 [details] /etc/apt/apt-conf.d/installer-cache-limit.conf Как будто число "размножилось", я такое точно не заптсывал.
(In reply to ruslandh from comment #60) > (Ответ для Ivan Zakharyaschev на комментарий #47) > > (In reply to ruslandh from comment #33) > > > Created attachment 10897 [details] [подробности] [details] > > > Вид падения > > > > > > Добавил все параметры, что Антон предлагал и что тут прочитал. > > > В этот раз упала по другому. > > > Машина ещё работает, если что, могу ещё что-нибудь через флешку скинуть. > > > > > > В некоторых файлах видна флешка, на неёё внимание не обращайте, я её позже > > > примонтировал > > > > То, что здесь видно -- это другая ошибка apt (и больше ничего на скриншоте > > нет). > > Пишу текстом для дуобства дальнейшего анализа. > > > > E: The package lists or status file could not be parsed or opened. > > E: Unable to truncate to 18446744073709551615 > > > > Последнее это из функции: > > > > bool FileFd::Truncate(unsigned long To) > > { > > if (ftruncate(iFd,To) != 0) > > { > > Flags |= Fail; > > return _error->Error("Unable to truncate to %lu",To); > > } > > > > return true; > > } > > Указанный размер -- это 64-битное -1: > > > > $ printf '%x\n' 18446744073709551615 > > ffffffffffffffff > > $ printf '%x\n' -1 > > ffffffffffffffff > > > > Посмотрю ещё по коду, что послужило источником этой ошибки. > > А вот тут интересно, в файле /etc/apt/apt-conf.d/installer-cache-limit.conf > совсем не то число, которое я записал. Как будто оно размножилось. > Сейчас приложу картину (буфер обмена вне графики не работает). Ну у меня было одно объяснение, как может получиться -1, просто это не очень релевантно для проблемы, так что я не стал дальше тут это выяснять. Это должно было быть огромное число в конфиге. strtol заменяет его на LONG_MAX, так что там все младшие биты 1. Потом оно обрезается до int. Т.е. функция чтения опции int-а FindI() довольно по-дурацки написана уже сама по себе. Потом при возврате из функции чтения опции FindI() оно сохраняется опять в long (точнее unsigned long), и там делается sign extend -- т.е. все старшие биты заполняются 1. И это мы видим.
(In reply to ruslandh from comment #61) > Created attachment 10904 [details] > /etc/apt/apt-conf.d/installer-cache-limit.conf > > Как будто число "размножилось", я такое точно не заптсывал. Спасибо за удовлетворение любопытства! Как такое туда записалось, мне, конечно, неизвестно. Даже не очень понятно, какое число было задумано. Оно какое-то не "круглое" ни по основанию 16, ни 10.
Ожидаемо: p10 5.15.46-un-def - ошибка
(In reply to ruslandh from comment #10) > Регрессия произошла между > kernel-image-un-def-5.15.43-alt1.x86_64 > и > kernel-image-un-def-5.15.44-alt1.x86_64 Побисектил. a5e2c8a4574a ломает поведение
Коммит a5e2c8a4574a меняет только drivers/char/random.c так что его влияние на medium/read error выглядит удивительным. Предлагаю тем кто может это воспроизвести - зарепортить баг в апстрим. Это, видимо, будет virtualbox[1], random ([2], [3]) и linux-scsi ([2], [4]). [1] https://www.virtualbox.org/wiki/Bugtracker [2] https://bugzilla.kernel.org/ [3] linux-kernel@vger.kernel.org [4] linux-scsi@vger.kernel.org
Может, у нас virtualbox криво собран? Третий раз ставлю education на апстримном [1] - пока не воспроизводится. На нашем из репозитория - падает [1] - https://www.virtualbox.org/wiki/Downloads
(In reply to Олег Соловьев from comment #67) > Третий раз ставлю education на апстримном пока не воспроизводится. Упало. Значит, кривой не vbox
Поищите багу у vb в багтрекере, если можно Или напишите, если нет.
(Ответ для Олег Соловьев на комментарий #68) > (In reply to Олег Соловьев from comment #67) > > Третий раз ставлю education на апстримном пока не воспроизводится. > > Упало. Значит, кривой не vbox Для лучшей воспроизводимости проблемы хорошо помогает запуск теста на чтение HDD, на котором находится iso-образ. Я запускал в gnome-disks такой тест.
С новыми 5.18 ядрами тоже проблемы имеются - "Issues related to Linux kernel 5.18": - https://www.virtualbox.org/ticket/20914 + https://www.virtualbox.org/changeset/94500/vbox + https://www.virtualbox.org/changeset/94501/vbox + https://www.virtualbox.org/changeset/94502/vbox + https://www.virtualbox.org/attachment/ticket/20914/vbox-linux-5.19.patch Также с новыми ядрам замечено нестабильное поведение: - https://unix.stackexchange.com/questions/705953/virtualbox-5-1-34-crashes-frequently-on-kernel-5-18 Ну, и вишенка на торте: - https://lore.kernel.org/lkml/7f01221d-f693-adf8-f5a5-d71944b44162@lwfinger.net/ > Surprisingly, the bisection pointed to commit 6e8ec2552c7d ("random: use > computational hash for entropy extraction"). I am very sure of the bisection as > the kernel built from the commit that immediately precedes this one, > cfb92440ee71 - a tag commit by Linus, runs correctly. То есть замечательные "улучшения" прилетели аж из 5.18-rc1: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.15.47&id=a5e2c8a4574a random: use computational hash for entropy extraction commit 6e8ec2552c7d13991148e551e3325a624d73fac6 upstream.
В общем, вердикт такой: https://lore.kernel.org/lkml/a86d59b4-8f83-1f32-bd52-4662d407d745@lwfinger.net/ > The bottom line and good news for Oracle/VirtualBox and those of us that package > VB for distros is that this is a kernel regression - which is a conclusion I > hesitated to make earlier. It is not a problem with VirtualBox, VB just exposes > the kernel problem. > > I certainly hope that this problem is fixed before 5.18 is released. If not, I > will need to campaign to prevent openSUSE Tumbleweed from switching to 5.18. > That would normally happen with the release of 5.18.1!
(Ответ для Evgeny Sinelnikov на комментарий #72) > В общем, вердикт такой: > https://lore.kernel.org/lkml/a86d59b4-8f83-1f32-bd52-4662d407d745@lwfinger. > net/ > > > The bottom line and good news for Oracle/VirtualBox and those of us that package > > VB for distros is that this is a kernel regression - which is a conclusion I > > hesitated to make earlier. It is not a problem with VirtualBox, VB just exposes > > the kernel problem. > > > > I certainly hope that this problem is fixed before 5.18 is released. If not, I > > will need to campaign to prevent openSUSE Tumbleweed from switching to 5.18. > > That would normally happen with the release of 5.18.1! Смешно. Ошибка была не только не исправлена в 5.18, но ещё и бекпортирована в 5.15. Там же выше написано, что есть патч, исправляющий проблему: Jason has created a patch entitled "random: do not use input pool from hard IRQs" that fixes the problem for me. It can be found at https://lore.kernel.org/lkml/20220510140025.81168-1-Jason@zx2c4.com/. I had expected this patch to be merged into the mainline kernel by now. Jason should be able to shed light on any delays. Т.е. проблема в том, что random брался с жёсткого диска, а если жёсткий диск чем-то занят, то будут проблемы. Вот это и наблюдали. Когда жёсткий диск ни чем особо не занят, проблемы нет. А чем он интенсивнее работает, тем проблема более вероятна. А если жёсткого диска нет совсем, то и проблему не воспроизвести.
> Ошибка была не только не исправлена в 5.18, но ещё и бекпортирована в 5.15. Видимо, считают, что ошибка уже исправлена - так как патч с фиксом, который сработал для Larry Finger, который репортил баг с 'crashes in VirtualBox' - ("random: do not use input pool from hard IRQs") - принят в стабильные ветки. И как я понимаю, crash'ей vb больше нет, есть ошибки чтения cd-rom. $ git describe --co stable/linux-5.15.y^{/'random: do not use input pool from hard IRQs'} v5.15.44~22 Предлагаю тем у кого воспроизводится новый баг зарепотрить его To: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: LKML <linux-kernel@vger.kernel.org>
Я считаю правильной формулировкой описания бага: "Нестабильная работа виртуальных машин в virtualbox на ядре 5.15.44 (на хосте) и новее при наличии жёсткого диска (на хосте)", потому что выяснилось следующее: 1. Неважно, где находится iso-образ и виртуальный HDD, на SSD или HDD. Важно, есть HDD или нет, и работает он в это время или ничего не делает. Чем имеющийся HDD на хосте активнее работает, тем вероятность ошибки выше. 2. При этом неважно, с чего идёт установка, с виртуального cd-rom или виртуально HDD. Я записал iso-образ на виртуальный HDD и воспроизвёл проблему. Также выяснилось, что ошибок чтения в dmesg у ядер 5.15.46 и 5.15.47 (на хосте) нет. 3. Воспроизвёл проблему с установкой live. Установка прерывается с ошибкой: "Error unpacking image image/live into /mnt/destination: 1" при выполнении unsquashfs.
Created attachment 10928 [details] failure w/o HDD (In reply to Антон Мидюков from comment #75) > 1. Неважно, где находится iso-образ и виртуальный HDD, на SSD или HDD. > Важно, есть HDD или нет, и работает он в это время или ничего не делает. Чем > имеющийся HDD на хосте активнее работает, тем вероятность ошибки выше. ...и я только что это опроверг на своём рабочем компе SSD накопитель SAMSUNG 980 PRO MZ-V8P250BW 250ГБ, M.2 2280, PCI-E 4.0 x4, NVMe HDD на компьютере отсуствуют.
В ядро 5.10.119 прилетели коммиты по random. Так что проблема с virtualbox теперь и на обоих ядрах в p10. Пользователь в телеграм на эту же проблему жалуется.
Собрал в пятницу таску 302239 в p10. Должна чинить это.
(Ответ для Valery Sinelnikov на комментарий #78) > Собрал в пятницу таску 302239 в p10. Должна чинить это. Ядро un-def с момента пятничной сборки успело обновиться. Таску нужно перезапустить: apt> install kernel-modules-virtualbox-un-def#6.1.34-alt2.331566.1:p10+302239.300.1.1@1655486622 ... Следующие пакеты имеют неудовлетворенные зависимости: kernel-modules-virtualbox-un-def#6.1.34-alt2.331566.1:p10+302239.300.1.1@1655486622: Для установки требует: kernel-image-un-def (= 1:5.15.46-alt1:p10+301661.100.1.1) E: Извините, `битые' пакеты $ rpm -q kernel-image-un-def | tail -1 kernel-image-un-def-5.15.47-alt1.x86_64 Для ядра std-def - новые модули прилетают.
(Ответ для Valery Sinelnikov на комментарий #78) > Собрал в пятницу таску 302239 в p10. Должна чинить это. Проверил,чинит еа соответствующих ядрах (kernel-image-std-def-5.10.121-alt1.x86_64 и kernel-image-un-def-5.15.46-alt1.x86_64) Но уже актуально kernel-image-un-def-5.15.47-alt1.x86_64
(Ответ для ruslandh на комментарий #80) > (Ответ для Valery Sinelnikov на комментарий #78) > > Собрал в пятницу таску 302239 в p10. Должна чинить это. > > Проверил,чинит еа соответствующих ядрах > (kernel-image-std-def-5.10.121-alt1.x86_64 и > kernel-image-un-def-5.15.46-alt1.x86_64) > > Но уже актуально kernel-image-un-def-5.15.47-alt1.x86_64 На ядре std-def 5.15.48-alt1 в Сизифе проблему больше не наблюдаю.
(Ответ для Антон Мидюков на комментарий #81) [...] > > На ядре std-def 5.15.48-alt1 в Сизифе проблему больше не наблюдаю. Насколько я знаю, пропатченный virtualbox уже в сизифе. В p10 только-только едет, толкаясь с появлением новых ядер. Гонку пакетов наблюдаю в этом я. Сейчас в p10 отправится 5.15.48 и опять по новой таску придётся пересобирать. Нужно этот процесс обновления ядер и тестирования исправленного virtualbox нужно как-то согласованно провести. Ещё один момент - это обновление модулей. Без новых модулей на том же релизе виртуализатора виртуальные машины больше не стартуют.
Проблема давно исправлена.
