можно ли переносить linux с одного железа на другое?

Нет, не в случае бубунты, по крайней мере - она бинарная. Но вот битая память у тебя вполне может быть, memtest в помощь.

в результате чего процесс ядром отправляется в «вечный сон».

Напиши нормально что ты там увидел, а не художественные аналогии. segfault? oom-kill?

1.Там в обсуждении было много чего про memtest, но не в памяти дело.
2.Причем здесь «бинарная», для «бинарной» скорее просится «да».

нормально что ты там увидел

в ссылке все есть, если Вам это интересно

При переносе системы есть ньюансы.

Существуют аттрибуты, которые содержаться не в самих файлах, а в файловой системе (пакеты должны быть установлены attr, acl).

Копирует ли эти аттрибуты cp -a я не знаю.

Я архивирую/бэкаплю систему tar-ом с дополнительными командами, которые архивируют/распаковавают эти аттрибуты: Как перенести систему на другой диск? (комментарий)

У меня был случай также, когда использовал tar без опции --numeric-owner и получил неконсистентную систему.

Касается ли это вашего случая я, к сожалению, не знаю.

Копирует ли эти аттрибуты cp -a я не знаю.

не копирует

Я переносил систему через dd.

У меня были проблемы с консистентностью системы после использоавния gparted/resize2fs.

Но это так, опыт локалхостника.

А что понимается под «консистентностью системы», в смысле, fsck ее контролирует?

С gparted были проблемы лет 12 назад, может сейчас пофикшено.

С resize2fs «игрался». Что точно было, не помню, просто с тех пор не использую.

Из всей этой связки только с parted никаких проблем, но с ним одним в вашем случае далеко не уедешь.

Проблемы типа фризов, «зависонов» и т.п.

segfault? oom-kill?

ТС не знает таких слов, давай ты ему переведёшь на русский и картинками зарисуешь?

а не может ли первоначально ядро быть настроено на особенности более продвинутого процессора и материнской платы?

Вероятность стремится к нулю, т.к. ядро и вообще пакеты в убунте собирают с минимальными флагами оптимизации, что-то вроде -march=x86_64 -mtune=generic

Добавь оперативки на слабый комп.

Вероятность стремится к нулю, т.к. ядро и вообще пакеты в убунте

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

Тогда может эта прога собрана чудно

В общем случае можно. Арч я так переносил. Но случае перехода на видеокарту от другого производителя (в смысле Nvidia, AMD, Intel, а не тот, кто собрал) придётся немного поколдовать с дровами.

Насчёт конкретно убунты, впрочем, не уверен. Они там намудрили сложности ради сложности, так что могут (как всегда с убунтой и использованием шаг в лево, шаг вправо от «стандартного») быть и подводные камни.

cp из GNU coreutils достаточно давно понимает xattr и с опцией ″-a″ или ″-p=xattr|all″ копирует xattr (команды getfattr, setfattr). Acl входит в xattr.

А вот атрибуты ext3, которые lsattr, chattr не копирует.

Но спрашивал то ТС именно про ядро. Не знаю, что подразумевалось под «ядро быть настроено», насколько я знаю, ubuntu при установке не занимается правкой параметров ядра (те, которые через загрузчик/конфиг груба предаются). Поэтому, что копируй, что устанавливай с нуля, ядро будет одинаковым и его параметры тоже будут одинаковыми. Плюс я не знаю, есть ли вобще параметры ядра, влияющие на выполнение кода, там в основном параметры драйверов устройств.

случайным образом что-то не успевает сделать

При таком описании, это уже похоже на кривой код с race condition...

Ясно. Я напутал xattr и chattr.
Кстати, как вообще работают эти ACL и SELinux? Какие ещё есть? Читал, Что некоторые программы, не поддерживающие ACL при создании файлов не наследуют полномочия.
Почему в tar разделено --acls --selinux --xattrs? --xattrs подразумевает все?
tmpfs все атрибуты поддерживает?

Обратите внимание, что в tar был баг, который неправильно транслировал acl вкупе с параметром numeric-owner.

Пофикшен 2023-05-18.

https://savannah.gnu.org/bugs/?61934

Всё запутано :) Изначально была простая идея, что пусть ФС система может хранить не только файл и его атрибуты (базовые), но и расширеные атрибуты (xattrs), в виде пар ИМЯ=ЗНАЧЕНИЕ. Для работы системные вызовы setxattr()/getxattr(). И гарантируется атомарность измения пары и как-бы всё.

Но этого показалось мало, придумали пространства имён (namespace) и имя приобрело вид: user.mime_type, system.posix_acl_access, security.selinux, security.capability. По имени двух последних понятно, для чего их использует ядро, и в этом случае оно не даёт записать произвольный мусор в этот параметр, а только данные в определённом формате. Обычный пользователь может изменять только параметры в namespace user. Всего в Linux: user, trusted, security, system.

То есть в linux используют xattrs для хранения ACL и SeLinux и пр.

В linux в текущей версией tar так:
# tar -c --xattrs  — занесёт в архив все xattr файла
# tar -x --xattrs  — установит у извлекаемых файлов только user.* атрибуты
# tar -x --xattrs --xattrs-include='*'  — установит у извлекаемых файлов все атрибуты

Но, не обязательно, что acl хранятся в xattr. POSIX определяет отдельный набор вызовов, типа acl_get_entry(), для работы с ACL. Я не знаю, что будет, если создавать tar-архив в Linux, а распаковывать на другой платформе, где ACL не хранится в xattr. Пожет ли тут создание архива через ″--xattrs --acls″ неясно.

Касательно tmpfs. Достаточно давно, а может с самого начала, она поддерживает ACL, что означает поддержку system.posix_acl_access. Пишут, что с 5.9 в конфигурации ядра можно указать CONFIG_TMPFS_XATTR, что даст trusted.* и security.*. Но user.*, вроде как, до сих пор не поддерживается.

не поддерживающие ACL при создании файлов не наследуют полномочия

Вроде нет, вроде автоматически при вызове create(). Разве что, если ФС смонтировать с отключеным ACL и тогда насоздавать файлов...

да я сделал pacstrap в виртуалке на hyperbola gnu/linux libre по мануалу и перенёс на флешку т.к. у меня на usb-live тогда не было интернета и нету исо с офлайн установкой, доустановил и запускается только через фалбак

с некоторыми ограничениями и условно, внутри одной аппаратной архитектуры - условно да, зависит от acpi, перефирии и содержимого ([/boot/config*|/proc/config*])