Выглядит так, как будто чинить надо в разбивке диска.

Да, тот коммит выглядит как багфикс.

(Ответ для Anton Farygin на комментарий #1)
> Выглядит так, как будто чинить надо в разбивке диска.

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

Перевешиваю на evms.

Created attachment 12255 [details]
Лог evms

(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;
}

У нас при перечитывании дисков они используются ?

Если да, то это ошибка.

Дело не в том что код делающий BLKRRPART простой и правильный, а что диск на котором он выполняется "exclusively open" - предположительно, собран в RAID1 массив.

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

В любом случае, это изменение уже есть и ради нашего инсталлера его вряд ли будут отменять, тем более если инсталлер не разбирает массив перед BLKRRPART, что выглядит не правильным.

(Ответ для Олег Соловьев на комментарий #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:

А почему мы перечитываем вообще все устройства, а не только те, у которых делали манипуляции с таблицей разделов?

>  Так что это ситуация где поломки с обоих сторон.

Кстати, libstorage-ng который упоминается в коммите это часть OpenSUSE инсталлера YaST. То есть они свой инсталлер чинили.

Можно не откатывать весь коммит у ядра, а только убрать одну проверку:

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.

Конечно не понятно зачем процесс alterator открывает и держит открытым блок девайс /dev/sda.

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

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

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

Если этот коммит ошибочный, то предлагаю написать об этом авторам коммита с детальным объяснением почему возникает такая ситуация и обоснованием почему она не правильная. Если это надо фиксить в ядро, то это надо проводить через апстрим.

(Ответ для Vitaly Chikunov на комментарий #11)
> Конечно не понятно зачем процесс alterator открывает и держит открытым блок
> девайс /dev/sda.
> 
> Но это повлияет на `bd_holder` только если устройство открыто с флагом
> `FMODE_EXCL` (или без него, но потом сделан вызов ioctl BLKBSZSET).
> 
> В остальных случаях, девайс открывается в эксклюзивном режиме [только] самим
> ядром при использовании его другими устройствами (например mdraid, drbd,
> btrfs, и т.д.) специально, чтоб заблокировать (в том числе и) изменение
> партишенов. (lsof таких держателей не покажет.)

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

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

Я не предлагаю фиксить ядро.

(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

Created attachment 12309 [details]
claim stack

Насколько я понял, устройство захватывается в open_table_device (почему-то не попал в стек)

Comment on attachment 12309 [details]
claim stack

А как сделан этот трейс?

(In reply to Vitaly Chikunov from comment #15)
> Comment on attachment 12309 [details]
> claim stack
> 
> А как сделан этот трейс?

dump_stack() в функции bd_finish_claiming

Так. Я нашёл что блокирует:

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

Вызываемая функция - activate()

Исправлено:
[#313097] DONE (try 3) evms.git=2.5.5-alt63 guile-evms.git=0.6.4-alt3 ...

Олег, спасибо!

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

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