Отлучить ядро Linux и консоль от последовательного порта

это изменить и сохранить настройку чтобы ядро не занимало порт.

а оно разве держит?
Это getty держит порт. Настройки в /etc/inittab (и вызов init q)

Ну ядерные логи загрузки туда точно не getty шлёт, он тогда ещё не запущен. Если после загрузки кроме getty никто с ним не общается то в какой момент этот переход происходит?

Кто с кем не общается?
Как я понимаю, пишет ядро в консоль или нет, определяется значениями в /proc/sys/kernel/print
Первое значение там это log level

       Kernel constant   Level value   Meaning
       KERN_EMERG             0        System is unusable
       KERN_ALERT             1        Action must be taken imme‐
                                       diately
       KERN_CRIT              2        Critical conditions
       KERN_ERR               3        Error conditions
       KERN_WARNING           4        Warning conditions
       KERN_NOTICE            5        Normal   but   significant
                                       condition
       KERN_INFO              6        Informational
       KERN_DEBUG             7        Debug-level messages

У меня там после загрузки стоит 1, так что ничего не пишется.
Если поставить 6 или 7, то будет писать в активный tty.
В какой момент и кто его переключает в 1, я не разбирался.

На serial порту пока не имею возможности проверить /proc/sys/kernel/print.
Но мне всегда хватало перенастройки inittab для работы с портом, который указан в параметрах ядра как serial console.

У systemd serial console запускается через serial-getty@ttySx.service

1. Отвязать ядро от порта нельзя, если оно на него настроилось. Наверное можно, если написать крохотный модуль ядра, но вроде штатной возможности нет.
2. Можно через настройку loglevel сделать так, чтобы ядро туда ничего не печатало, т.е. фактически можно сказать, что это отвяжет ядро от консоли, пока кто-нибудь не поменяет loglevel. Или через dmesg -D
3. За отображение login отвечает не ядро, ту программу, которая печатает login и ждёт ввода, надо настраивать отдельно и тут уже проблем быть не должно. Это или systemd или его аналоги.

Еще мысль. А можно ли как то запустить консольную программу так, чтобы она открылась на консоли, которая висит с этим портом, запускаю скажем через ssh/telnet. Но обычно stdin/stdout вешается на ту консоль откуда запускали

А есть ли способ указать stdin/stdout иной? Это бы решило задачу без плясок. Да, что то в фоне может туда сирануть, но такое редко и это можно игнорировать, а вот зацепившись за stdin/out можно спокойно туда писать, ASCII подойдет тоже

Если твоя программа будет писать в /dev/ttyS0, например ты её запустишь через myprogram > /dev/ttyS0 проблем не должно быть, её вывод будет пересекаться в выводом сообщений от ядра и getty, если первых не будет, то проблем не будет.

А вот если твоя программа будет читать из /dev/ttyS0 одновременно с запущенным getty, то данные будут уходить случайным образом в твою программу или в getty, в зависимости от того, кого разбудит планировщик. Поэтому чтение работать надёжно не будет. Если тебе надо принимать в программу данные из COM-порта, то тебе надо останавливать getty.

Т.е. тебе надо использовать что-то вроде

systemctl stop  serial-getty@ttyS0.service
myprogram </dev/ttyS0 >/dev/ttyS0 2>&1
systemctl start  serial-getty@ttyS0.service

Спасибо, про getty понял. Попробую так. У меня там не сисямдэ, а initrc какой то, наверное всё будет аналогично

  831 root      3640 S    {start_getty} /bin/sh /bin/start_getty 115200 ttyUL0
  846 root      3640 S    /sbin/getty -L 115200 ttyUL0 vt102

Действительно какой то getty торчит, прибитие не спасает и респавнит с новым pid, там видимо перезапуск в цикле. Поищу как сервис положить

В итоге с горем пополам отредактировал /etc/inittab через гомосяцкий убогий vi (нормального редактора не было, даже nano), закомментил getty с respawn, сохранил, telinit q вызвал, после killall -9 getty процессы getty для консоли больше в процессах не висят

Правда что без этого что с этим, доступ к /dev/ttyUL0 сохраняется через echo cat, надеюсь мешать не будет и заработает как надо

нормального редактора не было, даже nano

Что мешает удаленно редактировать конфиги через SFTP?