Bug 4360 - Виснет при инсталляции
: Виснет при инсталляции
Status: RESOLVED FIXED
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: x86_64 Linux
: Highest blocker
: 2014 Fresh R4
Assigned To: Konstantin Vlasov
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-04 16:37 MSD by Vladimir Potapov
Modified: 2014-09-23 18:55 MSD (History)
3 users (show)

See Also:
RPM Package:
ISO-related:
Bad POT generating:
Upstream:


Attachments
ss (3.22 MB, image/jpeg)
2014-09-04 16:37 MSD, Vladimir Potapov
Details
Strace log for diskdrake (shortened) (900.57 KB, text/plain)
2014-09-08 18:22 MSD, Eugene Shatokhin
Details
More detailed strace log (125.64 KB, application/octet-stream)
2014-09-09 11:12 MSD, Eugene Shatokhin
Details
journalctl -ab after running & killing diskdrake (158.12 KB, text/plain)
2014-09-09 11:12 MSD, Eugene Shatokhin
Details
Differences in packages between the builds 4885 (last good) and 5229 (first bad) (78.79 KB, text/plain)
2014-09-12 12:36 MSD, Eugene Shatokhin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Potapov 2014-09-04 16:37:02 MSD
Created attachment 3168 [details]
ss

Образ 5970 виснет при инсталляции на окошке "подождите" (см скриншот)
При инсталляции из меню виснет после ввода параметров, при инсталляции из лайва - сразу (но можно успеть увидеть как инсталлер сжирает всю память).
Comment 1 Vladimir Potapov 2014-09-04 17:03:05 MSD
В виртуальной машине ставится, т.е. дело в аппаратуре.
Comment 2 Vladimir Potapov 2014-09-04 17:05:17 MSD
возможно, по этой теме bug#4361
Comment 3 Eugene Shatokhin 2014-09-08 11:45:02 MSD
Если проявляется только на реальном железе, нужна ещё, как минимум, информация об оборудовании. Лучше - ссылку на данные, собранные hw-probe в Live mode.

В идеале, хорошо бы ещё и системный лог сохранить при установке. Если получится, очень помогло бы.
Comment 4 Eugene Shatokhin 2014-09-08 18:18:01 MSD
Проблема проявляется и при запуске diskdrake в Live mode. Сначала выдаются такие ошибки:

"cannot get info for device (7:0:0:0) at /usr/lib/libDrakX/detect_devices.pm line 222" 

"Warning: the driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes."

Затем diskdrake зависает и постепенно отъедает всё больше памяти. Судя по выводу strace, он открыл /dev/sdb (устройство, соотв. установочной флэшке), стал читать его блоками по 512 байт, не останавливаясь.

Пока неясно, почему он так делает.

В системном логе при этом есть такое сообщение:
"found MacOS at partition /dev/sdb8" - но на флэшке (/dev/sdb) такого раздела нет вообще. Там только sdb1 и sdb3. 
Опять-таки, судя по логу strace, перед открытием /dev/sdb загружается Perl'овый модуль /usr/lib/libDrakX/partition_table/mac.pm.
Comment 5 Eugene Shatokhin 2014-09-08 18:22:10 MSD
Created attachment 3190 [details]
Strace log for diskdrake (shortened)
Comment 6 Konstantin Vlasov 2014-09-08 22:09:20 MSD
Детально пока не анализировал, но ясно вижу, что в образе, действительно, есть какие-то ошмётки яблочных разделов. Поскольку разбивальщик диска не знает, чего ему ожидать, он перебирает функции чтения для каждого из известных типов таблиц разделов (как раз те самые partition_table/*.pm), и маковский видит куски родной структуры. Предположительно, дальше идёт мусор, на котором его и заглючивает.

Вообще, с таблицей разделов творится что-то страшное. Для начала, самих разделов получается почему-то три, хотя должно быть два. Во-первых, это ломает мой скриптик, который хачит таблицу разделов MBR после вызова isohybrid (наше решение проблемы с зависающими биосами HP-ноутов). Хак заключается в том, что первый (фейковый) раздел, занимающий весь диск, удаляется, а на его место ставится второй раздел - EFI. Данные второго раздела после этого забиваются нулями (что равносильно его удалению). Третий же раздел не трогается (скрипт не рассчитан на его появление), и в итоге таблица MBR получается невалидной (раздел-пусто-раздел). Как её после этого будут обрабатывать хоть драки, хоть другие программы, - боюсь даже предположить. Во-вторых, я посмотрел, куда вообще ссылается этот третий раздел - там всё оказалось забито нулями. То есть, совсем непонятно, зачем он нужен.

Далее, у нас в образе есть ещё и таблица разделов GPT. Так вот, если раньше она была нормальной, то в образе 5790 в ней тоже какие-то странности. Массив дескрипторов разделов начинается не со второго сектора, а с 16-го (формально это допустимо, но неясно, с чего вдруг добавился этот сдвиг); в самой таблице описаны ровно те же три раздела, что и в MBR. Но при этом, если раньше в наших образах неиспользуемое место было забито нулями, то теперь там время от времени попадаются какие-то куски бинарных данных со словами "Apple_HFS" и "Apple_partition_map", что как бы наводит на разные непристойные мысли.

Короче, я бы в первую очередь начал смотреть в сторону процедуры сборки образов. Конечно, зависание разбиватора, пусть даже на некорректных данных, - это в любом случае нехорошо, но с маковскими таблицами разделов я незнаком, и не уверен, что смогу за разумное время разобраться, что конкретно не нравится модулю mac.pm, и как это исправить.


P.S. Кстати, на будущее: при сборке strace-логов хорошо бы увеличивать длину строк хотя бы до 128 символов: там видны сообщения, отсылаемые куда-то в системные логи, но самих сообщений не видно, т.к. умолчальной длины хватило лишь на дату-время да название программы (diskdrake). А так, возможно, этот текст что-нибудь прояснил бы.

P.P.S. Скорее всего, в виртуалке проблема не воспроизводится из-за того, что на CD/DVD-дисках таблицы разделов просто игнорируются. Если на живой машине ставить не с флэшки, а с DVD-болванки, то, по идее, проблема тоже должна исчезнуть. А если в виртуалке, наоборот, загрузиться с этого образа как с обычного диска (например, сконвертировав ISO-файл в VDI), то проблема должна вылезти и там.
Comment 7 Vladimir Potapov 2014-09-09 05:44:34 MSD
По зависанию - там инсталлер ищет по порядку? Может этот мак в конец переставить?
Comment 8 Eugene Shatokhin 2014-09-09 11:12:00 MSD
Created attachment 3191 [details]
More detailed strace log
Comment 9 Eugene Shatokhin 2014-09-09 11:12:38 MSD
Created attachment 3192 [details]
journalctl -ab after running & killing diskdrake
Comment 10 Eugene Shatokhin 2014-09-09 11:15:25 MSD
(In reply to comment #6)
Спасибо, Костя, что подключился к этому делу.

Насчёт strace - разумно. Да и системный лог, действительно, пригодится. Я выложил вывод journalctl и более полный вывод strace.

Есть что-то, что на этой неделе я могу сделать по этому багу, пока ты в отпуске?
Comment 11 Konstantin Vlasov 2014-09-09 17:46:17 MSD
(In reply to comment #7)
> По зависанию - там инсталлер ищет по порядку? Может этот мак в конец
> переставить?

mac.pm и так последний.


(In reply to comment #10)
> Есть что-то, что на этой неделе я могу сделать по этому багу, пока ты в
> отпуске?

Не знаю, имеет ли смысл загружать этим именно тебя, но если есть время и желание, можно проделать что-нибудь в направлении поиска источника проблемы. Когда я выйду из отпуска, я планирую для начала попробовать найти двоичным поиском первый образ с этой багой, определив, какой конкретно коммит (или серия коммитов) в сборочных скриптах привёл к такой ситуации. Проверить, не пролезло ли то же самое в последние сборки 2012.1. При обнаружении соответствующего коммита попробовать пересобрать образ с последней рабочей версией скриптов, чтобы узнать, проблема в скриптах или в пакетах из репозитория (ключевой из них - livecd-tools). Если баг повторится - посмотреть, какая версия livecd-tools была актуальной на момент сборки последнего рабочего образа; откатиться на неё в персональный реп, пересобрать образ с этой версией. Ну и дальше по обстоятельствам. Соответственно, если что-то из этого будет уже проделано другими сотрудниками, проблема будет решена быстрее.
Comment 12 FirstLevel 2014-09-09 19:10:51 MSD
Протестировал установку 64битной версии на HP 6465b.
На ноутбуке стоит Марафон, Фреш, Винда 7 и последней успешно поставилась 2014 32-битная.
При попытке установить 2014 64-битную инсталлятор повис с окном "Пожалуйста, подождите" перед этапом разбиения дисков. Висел больше часа и я полагаю, что уже бы и не отвис.
Т.е. у меня тоже 64битная 2014 РОСА не ставится на реальное железо.
Comment 13 Vladimir Potapov 2014-09-10 13:13:03 MSD
Образ 5994, актуально
Comment 14 FirstLevel 2014-09-10 18:49:39 MSD
(In reply to comment #13)
> Образ 5994, актуально

Владимир, пиши разрядность.
Comment 15 Vladimir Potapov 2014-09-11 16:09:19 MSD
(In reply to comment #14)
> (In reply to comment #13)
> > Образ 5994, актуально
> 
> Владимир, пиши разрядность.

Теперь вот проверил на x32. 6009 x32 не наблюдается, поставил нормально.
Comment 16 Eugene Shatokhin 2014-09-12 12:34:31 MSD
Костя, вот что удалось выяснить на данный момент (я проверял только 64-битные образы на нашем тестовом стенде, если что).

1.
Последний образ 2014.1, где diskdrake стартует нормально - 4885 (собран 8 июля). 
Там при старте, кстати, выводится та же ошибка "cannot get info for device (7:0:0:0) ...", но warning'ов про physical block size нет, а diskdrake запускается нормально. Т.е., возможно, ругань на device 7:0:0:0 к данной проблеме отношения не имеет.

2. 
Первый образ 2014.1, где проблема проявляется - 5229 (собран 28 июля). Diskdrake висит при старте, а в логах - то же сообщение про MacOS. 

Образы, подготовленные после 4885, но до 5229, не загрузились на тестовом стенде, так что сузить диапазон поиска сильнее не получилось.

GNOME'овские образы для 2014.1 я тоже смотрел, но там в этом диапазоне рабочих образов тоже не нашлось.

3.
На первый взгляд, каких-то подозрительных коммитов между 8 и 28 июля в сборочных скриптах (https://abf.rosalinux.ru/soft/build_kde4_desktop_ee/commits/rosa2014.1) не видно, хотя может, я чего и не заметил.

4.
Отличия в списке пакетов между образом 4885 и 5229 прикреплю ниже. Отличий довольно много там, правда, вплоть до ядра.

5. 
Я посмотрел в 2012.1 (образ 5549 из rosa2012.1_ee и 5711 из rosa2012.1_ee_tests, самые свежие на тот момент). 

Там проблема не проявляется. Diskdrake стартует нормально. Ругается на device 7:0:0:0, но это, как я говорил, вероятно, не имеет отношения к проблеме.
Comment 17 Eugene Shatokhin 2014-09-12 12:36:57 MSD
Created attachment 3201 [details]
Differences in packages between the builds 4885 (last good) and 5229 (first bad)
Comment 18 Vladimir Potapov 2014-09-12 12:52:28 MSD
Андрей говорил что-то о глючном gcc. Он как раз появился в это время.
Comment 19 Andrey Bondrov 2014-09-14 17:41:40 MSD
Возможно, проблема не в последнюю очередь связана с тем, что 64-битный пакет drakx-installer-binaries у нас не пересобирается и никто его ещё не починил.
Comment 20 Konstantin Vlasov 2014-09-22 23:49:57 MSD
Попробуйте этот образ:
https://abf.rosalinux.ru/platforms/rosa2014.1/products/111/product_build_lists/6261
Comment 21 Vladimir Potapov 2014-09-23 03:17:33 MSD
Работает.
Comment 22 Vladimir Potapov 2014-09-23 03:26:30 MSD
Т.к. билд тестовый, баг пока  не закрываю.
Comment 23 FirstLevel 2014-09-23 10:00:27 MSD
На ноут HP 6465b  также успешно установил 64битный образ 6261
Comment 24 Vladimir Potapov 2014-09-23 10:24:23 MSD
Но режим UEFI все так же не загружается. Впрочем, это другой баг.
Comment 25 Konstantin Vlasov 2014-09-23 13:26:34 MSD
Да, проблему с UEFI пока не решал.
Спасибо за подтверждение, буду выносить исправления в основную ветку.
Comment 26 Konstantin Vlasov 2014-09-23 18:55:11 MSD
Исправлено в основной ветке:
https://abf.rosalinux.ru/platforms/rosa2014.1/products/86/product_build_lists/6280