Bug 44880 - Установка не может пройти дальше шага разбивки диска инсталятором, из-за невозможности перечитать таблицы разделов
Summary: Установка не может пройти дальше шага разбивки диска инсталятором, из-за нево...
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: evms (show other bugs)
Version: unstable
Hardware: all Linux
: P5 normal
Assignee: Олег Соловьев
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 33000
  Show dependency tree
 
Reported: 2023-01-11 08:25 MSK by Антон Мидюков
Modified: 2023-01-24 14:45 MSK (History)
6 users (show)

See Also:


Attachments
Невозможно перечитать разделы (48.94 KB, image/png)
2023-01-11 08:25 MSK, Антон Мидюков
no flags Details
Лог evms (90.04 KB, text/plain)
2023-01-11 09:35 MSK, Антон Мидюков
no flags Details
claim stack (19.65 KB, image/png)
2023-01-17 11:16 MSK, Олег Соловьев
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Антон Мидюков 2023-01-11 08:25:08 MSK
Created attachment 12254 [details]
Невозможно перечитать разделы

На ядрах un-def-6.0.18-alt1 и un-def-6.0.17-alt1 установка не может пройти дальше шага разбивки диска инсталятором, из-за невозможности перечитать таблицы разделов.
Помогает реверт коммита 3e493bb289de72c3f6de3aca74603a81ce0f49dd
Собрал тестовое задание для проверки #313144

Коммит https://git.altlinux.org/people/kernelbot/packages/?p=kernel-image.git;a=commit;h=3e493bb289de72c3f6de3aca74603a81ce0f49dd
Comment 1 Anton Farygin 2023-01-11 08:37:06 MSK
Выглядит так, как будто чинить надо в разбивке диска.
Comment 2 Vitaly Chikunov 2023-01-11 08:40:18 MSK
Да, тот коммит выглядит как багфикс.
Comment 3 Антон Мидюков 2023-01-11 08:48:17 MSK
(Ответ для Anton Farygin на комментарий #1)
> Выглядит так, как будто чинить надо в разбивке диска.

(Ответ для Vitaly Chikunov на комментарий #2)
> Да, тот коммит выглядит как багфикс.

Перевешиваю на evms.
Comment 4 Антон Мидюков 2023-01-11 09:35:26 MSK
Created attachment 12255 [details]
Лог evms
Comment 5 Олег Соловьев 2023-01-11 10:36:26 MSK
(In reply to Anton Farygin from comment #1)
> Выглядит так, как будто чинить надо в разбивке диска.

По ссылке на коммит:
This partition device under a raid device confuses
some programs (such as libstorage-ng used for initial partitioning for
distribution installation) leading to failures.

По описанию -- апстримный коммит чинит поведение какого-то ПО, не имеющего никакого отношения к нашим дистрибутвами, но при этом ломает использующееся у нас ПО, что нарушает принцип do not break userspace.

Пока наш установщик "прожёвывает" странные с точки зрения апстрима конфигурации дисков -- чинить нечего, поэтому просьба не ломать это со стороны ядра.

Код для перечитывания таблицы разделов прост как топор и вообще находится в guile-evms:
static int evms_reread_ptable(char *devname)
{
        int fd, i;
        if ((fd = open(devname, O_RDONLY)) < 0)
                return 0;
        i = ioctl(fd, BLKRRPART);
        close(fd);
        return i;
}
Comment 6 Anton Farygin 2023-01-11 10:38:19 MSK
У нас при перечитывании дисков они используются ?

Если да, то это ошибка.
Comment 7 Vitaly Chikunov 2023-01-12 10:12:38 MSK
Дело не в том что код делающий BLKRRPART простой и правильный, а что диск на котором он выполняется "exclusively open" - предположительно, собран в RAID1 массив.

С точки зрения того коммита они фиксят баг 2020 года. Да это поломало нам userspace, но тот коммит 2020, который они фиксят, видимо тоже ломал userspace. Так что это ситуация где поломки с обоих сторон.

В любом случае, это изменение уже есть и ради нашего инсталлера его вряд ли будут отменять, тем более если инсталлер не разбирает массив перед BLKRRPART, что выглядит не правильным.
Comment 8 Антон Мидюков 2023-01-12 20:06:32 MSK
(Ответ для Олег Соловьев на комментарий #5)
> (In reply to Anton Farygin from comment #1)
> > Выглядит так, как будто чинить надо в разбивке диска.
> 
> По ссылке на коммит:
> This partition device under a raid device confuses
> some programs (such as libstorage-ng used for initial partitioning for
> distribution installation) leading to failures.
> 
> По описанию -- апстримный коммит чинит поведение какого-то ПО, не имеющего
> никакого отношения к нашим дистрибутвами, но при этом ломает использующееся
> у нас ПО, что нарушает принцип do not break userspace.
> 
> Пока наш установщик "прожёвывает" странные с точки зрения апстрима
> конфигурации дисков -- чинить нечего, поэтому просьба не ломать это со
> стороны ядра.
> 
> Код для перечитывания таблицы разделов прост как топор и вообще находится в
> guile-evms:

А почему мы перечитываем вообще все устройства, а не только те, у которых делали манипуляции с таблицей разделов?
Comment 9 Vitaly Chikunov 2023-01-13 01:57:29 MSK
>  Так что это ситуация где поломки с обоих сторон.

Кстати, libstorage-ng который упоминается в коммите это часть OpenSUSE инсталлера YaST. То есть они свой инсталлер чинили.
Comment 10 Антон Мидюков 2023-01-17 05:33:17 MSK
Можно не откатывать весь коммит у ядра, а только убрать одну проверку:

diff --git a/block/genhd.c b/block/genhd.c
index c4765681a8b4b..e799e706133c1 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -366,9 +366,6 @@ int disk_scan_partitions(struct gendisk *disk, fmode_t mode, void *owner)
                return -EINVAL;
        if (disk->open_partitions)
                return -EBUSY;
-       /* Someone else has bdev exclusively open? */
-       if (disk->part0->bd_holder && disk->part0->bd_holder != owner)
-               return -EBUSY;
 
        set_bit(GD_NEED_PART_SCAN, &disk->state);
        bdev = blkdev_get_by_dev(disk_devt(disk), mode, NULL);

Без этой проверки установка проходит успешно. Проверено на задании 313560, ядро 6.1.6-alt1.1, отличающееся от 6.1.6-alt1 только этой правкой.

Ну и это наводит на мысль, что перечитывает один процесс, а держит другой.
Кто держит /dev/sda, известно:
lsof /dev/sda
COMMAND    PID USER FD   TYPE  DEVICE SIZE/OFF    NODE NAME 
alterator 1973 root 23u  BLK      8,0 0x000000000 302  /dev/sda

PID 1973 в данном случае соответствует:
/usr/bin/guile --no-auto-compile /usr/sbin/alteratord

А какой процесс перечитывает, мне неизвестно.
Возможно, порождается дочерний процесс при выполнении evms_reread_ptable? Тогда он не будет иметь право перечитывать /dev/sda, так как его занимает alteratord.
Comment 11 Vitaly Chikunov 2023-01-17 08:12:53 MSK
Конечно не понятно зачем процесс alterator открывает и держит открытым блок девайс /dev/sda.

Но это повлияет на `bd_holder` только если устройство открыто с флагом `FMODE_EXCL` (или без него, но потом сделан вызов ioctl BLKBSZSET).

В остальных случаях, девайс открывается в эксклюзивном режиме [только] самим ядром при использовании его другими устройствами (например mdraid, drbd, btrfs, и т.д.) специально, чтоб заблокировать (в том числе и) изменение партишенов. (lsof таких держателей не покажет.)

Отключать эту рационально выглядящую проверку у нас было бы странным. После этого у нас вечно будет такое отличие наших ядер от апстримных? (Кроме того, изменение внутренней логики такого рода инвалидирует для нас тестирование ядер апстримом.)

Если этот коммит ошибочный, то предлагаю написать об этом авторам коммита с детальным объяснением почему возникает такая ситуация и обоснованием почему она не правильная. Если это надо фиксить в ядро, то это надо проводить через апстрим.
Comment 12 Антон Мидюков 2023-01-17 08:26:34 MSK
(Ответ для Vitaly Chikunov на комментарий #11)
> Конечно не понятно зачем процесс alterator открывает и держит открытым блок
> девайс /dev/sda.
> 
> Но это повлияет на `bd_holder` только если устройство открыто с флагом
> `FMODE_EXCL` (или без него, но потом сделан вызов ioctl BLKBSZSET).
> 
> В остальных случаях, девайс открывается в эксклюзивном режиме [только] самим
> ядром при использовании его другими устройствами (например mdraid, drbd,
> btrfs, и т.д.) специально, чтоб заблокировать (в том числе и) изменение
> партишенов. (lsof таких держателей не покажет.)

Спасибо за пояснение. evms создаёт устройства /dev/dm-0, /dev/dm-1 и так далее для каждого раздела. Наверное, это и есть эксклюзивное блокирование?

> 
> Отключать эту рационально выглядящую проверку у нас было бы странным. После
> этого у нас вечно будет такое отличие наших ядер от апстримных? (Кроме того,
> изменение внутренней логики такого рода инвалидирует для нас тестирование
> ядер апстримом.)
> 

Я не предлагаю фиксить ядро.
Comment 13 Vitaly Chikunov 2023-01-17 08:39:06 MSK
(In reply to Антон Мидюков from comment #12)
> Спасибо за пояснение. evms создаёт устройства /dev/dm-0, /dev/dm-1 и так
> далее для каждого раздела. Наверное, это и есть эксклюзивное блокирование?

Тут сложно сказать навскидку по одному коду.

По идее ядро создает симлинки в sysfs

 * - from "slaves" directory of the holder @disk to the claimed @bdev
 * - from "holders" directory of the @bdev to the holder @disk
 *
 * For example, if /dev/dm-0 maps to /dev/sda and disk for dm-0 is
 * passed to bd_link_disk_holder(), then:
 *
 *   /sys/block/dm-0/slaves/sda --> /sys/block/sda
 *   /sys/block/sda/holders/dm-0 --> /sys/block/dm-0
Comment 14 Олег Соловьев 2023-01-17 11:16:52 MSK
Created attachment 12309 [details]
claim stack

Насколько я понял, устройство захватывается в open_table_device (почему-то не попал в стек)
Comment 15 Vitaly Chikunov 2023-01-17 12:43:26 MSK
Comment on attachment 12309 [details]
claim stack

А как сделан этот трейс?
Comment 16 Олег Соловьев 2023-01-17 13:30:38 MSK
(In reply to Vitaly Chikunov from comment #15)
> Comment on attachment 12309 [details]
> claim stack
> 
> А как сделан этот трейс?

dump_stack() в функции bd_finish_claiming
Comment 17 Олег Соловьев 2023-01-18 11:18:17 MSK
Так. Я нашёл что блокирует:

evms_commit_changes() внутри себя через цепочку вызовов делает ioctl DM_TABLE_LOAD.

Вызываемая функция - activate()
Comment 18 Антон Мидюков 2023-01-24 07:05:45 MSK
Исправлено:
[#313097] DONE (try 3) evms.git=2.5.5-alt63 guile-evms.git=0.6.4-alt3 ...

Олег, спасибо!
Comment 19 Vitaly Chikunov 2023-01-24 14:45:24 MSK
(In reply to Антон Мидюков from comment #18)
> Исправлено:
> [#313097] DONE (try 3) evms.git=2.5.5-alt63 guile-evms.git=0.6.4-alt3 ...
> 
> Олег, спасибо!

Присоединяюсь, спасибо!