[make-initrd] root=<any> --> mount event handler / 900-localdev regression

[Leonid Krivoshein]

On 2/11/24 17:54, Alexey Gladkov wrote:
> On Sun, Feb 11, 2024 at 04:57:20AM +0300, Leonid Krivoshein wrote:
>> Привет!
>>
>>
>> Раньше методы загрузки и их смена были частью документации make-initrd.
>> Кажется, в этой логике что-то поломалось или поменялось несовместимым
>> образом. Сейчас концовка шага pipeline rootfs выглядит так:
>>
>> echo localdev > /etc/initrd/method
>> exit 2
>>
>> Исходим из предположения, что root=pipeline как бы должен поменяться на
>> другой метод загрузки, т.е. localdev, но как бы не так, хотя раньше
>> именно так и было. Отработав, демон мог передать управление другому
>> коду.
> Сейчас ровно так и происходит. Когда работает pipeline, то
> /etc/initrd/method = pipeline. Шаг rootfs переключает method=localdev. Это
> происходит в очереди событий pipeline. Это разблокирует обработчик в
> очереди mount.
>
> Возможно рейс может случиться из-за того, что method меняется до операции
> mount. Наверное правильнее было бы сделать так:
>
> --- a/features/pipeline/data/lib/pipeline/rootfs
> +++ b/features/pipeline/data/lib/pipeline/rootfs
> @@ -12,4 +12,4 @@ done
>
> -run mount --move "$prevdir" "$rootmnt"
>   echo localdev > /etc/initrd/method
> +run mount --move "$prevdir" "$rootmnt"
>   exit 2
>
> В остальном я не вижу тут других рейсов.
>
>> Сейчас же работают сразу две вещи:
>>
>> 1. Обработчики событий монтирования.
>> 2. 900-localdev работает всегда и с самого начала.
>>
>> Что в этом плохого? Гонки. Потому что цепочка действий (pipeline,
>> bootchain) не отработала, а параллельно начинает какой-то код что-то
>> делать. Если сейчас заменить концовку шага rootfs на:
>>
>> exit 2
>>
>> ничего не поменяется. До этого шага всё может даже не дойти, а
>> закончится раньше. А если по каким-то причинам цепочка "застрянет", мы
>> увидим что-то вроде:
> Она "застрянет" лишь потому что method всё ещё pipeline.
>
>> initramfs: Waiting for root (pipeline) ...
>>
>> даже после выполнения команды "echo localdev > /etc/initrd/method", т.к.
>> 100-rootdelay не перечитывает теперь изменённое значение, он берёт $ROOT
>> из /proc/cmdline.
> $ git ls-tree -r master | grep rootdelay
> 100755 blob c4dfb325061456cd3c9e47a12c5043d97126c2a5 data/etc/rc.d/init.d/rootdelay
> 100755 blob b6624fbd8ec095f1a48e2a4b50a7ad771f367d4c data/sbin/rootdelayd
>
> Я не знаю про какой 100-rootdelay ты говоришь. Его нет уже как с 9 июля
> 2023.
>
>> Как правильно избежать этих гонок?
> Одно потенциальное место гонки я предложил исправить выше. О каких ещё
> местах ты говоришь я пока не понимаю.
>
>> Как отключить на время обработки цепочки обработку mount и localdev?
> Все эвенты в очереди mount в handlers/mount/900-localdev игнорируются пока
> method не localdev.

К сожалению, это не так. В начале chaind выставляет метод в пустоту. Как 
только выполняется mount --move ... $rootmnt, тут же начинают 
срабатывать события mount/localdev, что видно по /var/log/uevents.log и 
по совпадению временных метод в /var/log/chaind.log.

Выше там у тебя всего одна команда. Подразумевается, что твой демон 
pipeline после этого шага rootfs тут же завершится. А если нет? В 
bootchain есть какая-то логика после шага rootfs. И в параллель с ней 
начинали отрабатывать эти события. В общем, мне удалось всё это 
победить, выполняя команду mount --move ... $rootmnt самой последней в 
chaind, т.е. непосредственно перед завершением демона.

>> И как включить их обратно после того, как цепочка отработает?
> Записать в /etc/initrd/method значение localdev и переместить/смонтировать
> в rootmnt все необходимые устройства.

Именно так я и сделал. То есть, теперь эти две команды -- завершение 
chaind, а не шага rootfs.


-- 
WBR, Leonid Krivoshein.