[devel] [#214195] DONE installer.git=1.8.43-alt1

[Leonid Krivoshein]

06.10.2018 11:14, Michael Shigorin пишет:
> On Fri, Oct 05, 2018 at 08:56:48PM +0000, Girar Builder pender robot wrote:
>> http://git.altlinux.org/tasks/archive/done/_209/214195/logs/events.1.1.log
>>
>> 2018-Oct-05 20:45:59 :: task #214195 for sisyphus started by mike:
>> #100 build 1.8.43-alt1 from /people/mike/packages/installer.git fetched at 2018-Oct-05 20:45:59
> [...]
>> 2018-Oct-05 20:56:48 :: task #214195 for sisyphus DONE
> Это я вчера напоролся в очередной раз на то, что у нас после
> инсталятора очень давно уже корневая файловая система вновь
> установленной системы остаётся неотмонтированной -- на этот
> раз опять выпало неоткатываемое состояние журнала, т.е. отказ
> загрузки системы до fsck (которого в initrd, разумеется, нет).
>
> Буду благодарен, если заинтересованные отсмотрят коммиты:
> http://git.altlinux.org/people/mike/packages/?p=installer.git;a=summary
>
> Ещё там надо бы поправить обработку ключевого слова poweroff:
> https://bugzilla.altlinux.org/show_bug.cgi?id=35479
>

Про юмор:

 > still broken for me: catches the keyword but reboots

Не удивительно, ведь чтобы need_poweroff включился, у тебя /proc 
_не_должен_ быть смонтирован (!) и ещё много чего... А если 
need_poweroff таки включился, /proc здесь же отмонтируется (!), после 
чего запись в /proc/sysrq-trigger не работает и много чего ещё, 
например, больше ничего уже нельзя отмонтировать. :)

mount -n -t proc none /proc
mount: /proc: none already mounted or mount point busy.


А по существу:

Не похоже, что /etc/rc.d/init.d/halt из startup определяет нынче логику 
выключения. Понять бы, что там с systemd, не евойные ли юниты виноваты в 
некоторых странностях при отработке логики выключения. У меня, к 
примеру, SWAP поверх 0-го LVM-рейда деактивируется исправно всегда. На 
машинах же со SWAP'ом поверх MD-рейдов он с завидной стабильностью не 
деактивируется и при каждом запуске systemd честно ждёт минуты полторы 
рабочего SWAP'а, но из-за того, что не отработал mdadm -S /dev/mdX после 
swapoff /dev/mdX при выключении. Вот это точно надо чинить до P9. 
Наиболее часто в логах systemd вижу проблемы при отмонтировании /var/run:

Unmounting Runtime Directory...
umount: /var/run: target is busy
         (In some cases useful info about processes that
          use the device is found by lsof(8) or fuser(1).)
var-run.mount: Mount process exited, code=exited status=32
Failed unmounting Runtime Directory.

и значительно реже:

umount: /run/user/500: not mounted
run-user-500.mount: Mount process exited, code=exited status=32
Unmounted /run/user/500.
run-user-500.mount: Unit entered failed state.

Но это на моей рабочей машине. Вот если кто знает, используется ли 
systemd во время инсталляции, и как дебажить в нём размонтирование 
корня, будет сподручней. Всей этой логике выключения/размонтирования в 
инсталляторе не место, IMHO. А с /destination так вообще костыли для 
бага -- в desktop-инсталляторе у меня ещё и рекурсивно раз 150 это всё 
монтировалось. То есть не со следствием бороться надо, а искать источник 
ошибки.


-- 
Best regards,
Leonid Krivoshein.