LINUX.ORG.RU
решено ФорумAdmin

Странности минисистемы (initrd)

 


0

2

Здравствуйте, коллеги!

Есть задумка сделать супер минималистичную систему на баз Altlinux (к сожалению в выборе донора я ограничен).

Всю систему я хочу запилить в initrd.

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

На данном этапе я получил адекватный ввод в баше и поднял сеть.

Что, вообще, делается в initrd (init) на текущий момент:

1. монтируются виртуальные fs (proc, sys, dev, dev/pts, run, tmp)
2. запускается udevd
3. запускаю bash

Вот тут начинается первая проблемка: система не воспринимает Ctrl-C. Т.е. нельзя выбить программу. Видимо нужно что-то подгрузить, но что?

Дальше я назначаю статический IP:

ip a add 192.168.0.100/24 dev eth0

Соответственно, уже есть в системе сетевые адаптеры (eth0, eth1), к eth0 подключен сетевой кабель.

Поднимаю eth0

ip link set up dev eth0

Все нормально, но не совсем…

Поскольку мне нужна только локальная сеть 192.168.0.0/24 то можно не прописывать gateway. Тут по желанию. Ни на что не влияет.

Вот тут получаю первую странность:

Пингую с другой машины (192.168.0.65) адрес минисистемы 192.168.0.100 и… Destination Host Unreachable

Теперь с минисистемы пингую 192.168.0.65. Пинги проходят! Сеть жЫвет!

После «входящего» пинга 192.168.0.65 может пинговать 192.168.100. Все работает. Но… На пинги минисистема начинает отвечать лишь после того, как сама кого-то пинганула.

И еще странность: минисистема не может пинговать свой ip (192.168.0.100). Вообще ни как!

Дальше я написал на C элементарный UDP эхо сервер и запускаю его на минисистеме. Все нормально! Я с ним могу «переговариваться».

Вот только… Через какое-то время миниситема перестает отзываться и виснет наглухо. Так, что даже на Ctrl-Alt-Del перестает реагировать.

Виноват не мой эхо сервер. Минисистема так же прекрасно виснет на bashe. Вот только что жила, а теперь сдохла.

Временной интервал до зависания разный. От нескольих минут до часа. Но, тем не менее, минисистема переходит в полную «несознанку» и лечится это только резетом.

Как будто минисистема засыпает, а проснуться уже не может. Но как такое может быть???

При этом, чем дольше общаешься с минисистемой по сети или с клавиатуры, то она ведет себя адекватно. Но стоит на какое-то время ее оставить в покое, как она засыпает мертвым сном.

Почему происходят эти засыпания - вообще не понимаю.

Почему минисистема не отвечает по сети до тех пор пока сама кого-то не пинганет - не понятно.

Как заставить миниситему реагировать на Ctrl-C?


Пинг - у тебя система не отвечает на arp-запросы. Но свои шлёт, по ним её и запоминают чтоб пинговать после того как она сама о себе заявила.

Набери dmesg -TW и посмотри что последнее будет в логе перед зависанием.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Набери dmesg -TW и посмотри что последнее будет в логе перед зависанием.

Хм.. initrd - read only образ!

При каждой загрузке она начинает жизнь с чистого листа.

Соответственно, от куда dmesg брать информацию о прошлой жизни?

Или я что-то не правильно понимаю?

HighMan
() автор топика

Кстати…

Некоторые тесты показали удивительное.

Если минисистема висит на bash, по так висеть она может долго и даже на пинги отвечает. Тоже когда ни будь зависнет, но не быстро.

А вот при запущенном моем эхо сервере зависает довольно быстро, если нет сетевого общения.

Такое впечатление, что если прога долго висит на recvfrom, то она сдыхает.

HighMan
() автор топика
Ответ на: комментарий от HighMan

dmesg ничего прошлого не показывает и к диску не обращается. Речь про текущий сеанс - запусти его и жди пока повиснет, потом на зависшей консоли смотри что последнее в неё вывелось.

firkax ★★★★★
()

bash нужно правильно запускать, чтобы он был лидером сеанса: can't access tty; job control turned off

По поводу пинга, лучше посмотрите tcpdump'ом, исходно, после установки адреса, приходят ли на него arp-запросы/icmp-пакеты, если принговать с 192.168.0.65. Может у вас свич придуривается, и не передаёт на порт пакеты, пока с порта пакет не придёт. ЕМНИП, при поднятии сетевого интерфейса принято отправлять ARP ответ (arping -U).

Что касается зависаний, то у вас есть уверенность, что это не аппаратный глюк? У меня, допустим, rpi zero просто висла с любой USB-сетёвкой, от часа до 12 часов работала, не более.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

Мне, как раз, сама система не нужна :)

Мне, фактически, нужно ядро и моды. Все остальное мне нужно постольку-поскольку пока все работает в тестовом режиме.

Кстати, а как запустить систему минуя initrd?

Т.е. как сказать ядру что бы оно передало управление сразу /sbin/init рутовой фаловой системы, например ext4?

HighMan
() автор топика
Последнее исправление: HighMan (всего исправлений: 1)
Ответ на: комментарий от mky

Что касается зависаний, то у вас есть уверенность, что это не аппаратный глюк? У меня, допустим, rpi zero просто висла с любой USB-сетёвкой, от часа до 12 часов работала, не более.

Ну, можно сказать, что я запускаю «минисистему» на почти обычном ПК на атоме.

Там я просто в хостовой системе (Altlinux) отредактировал bash.cfg что бы он загружал мое творчество или хостовый altlinux.

Сама хостовая система, при абсолютно одинаковом оборудовании, нормально крутится месяцами. И мой коленочный эхо сервер, так же, может работать сколь угодно долго.

А вот в минисистеме эхо сервер через какое-то время вешает систему.

Что же касается лидера сеанса, то большое спасибо! Поизучаю!

HighMan
() автор топика
Последнее исправление: HighMan (всего исправлений: 1)
Ответ на: комментарий от firkax

dmesg ничего прошлого не показывает и к диску не обращается. Речь про текущий сеанс - запусти его и жди пока повиснет, потом на зависшей консоли смотри что последнее в неё вывелось.

Все гениальное просто! :)

Токма dmesg ни чего полезного, в данном случае, не говорит.

Все еще интереснее!

Я сделел по совету mky и теперь у меня Ctrl-C нормально выбивает программы. Спасибо ему огроменное!

В общем, внезапно минисистема перестала отдуплятся по сети. На ней запущен мой эхо сервер.

Опа! Минисистема реагирует на клавиши и удалось выбить эхо сервер.

Полез в dmesg и… И НИЧЕГО!

Последний мессадж чуть не получасовой давности. Там он сообщает, что eth0 перешел в UP. Больше ни чего нет, но сеть на минисистеме не работает!

eth0 в апе, IP верный, но пинги и арпинги не идут.

Я его и так и эдак. Со словами и без слов…

Все в порядке, токма сеть не работает.

В конце концов:

ip link set down dev eth0
ip link set up dev eth0

И сеть снова заработала!

Что за чудеса чудесатые?

HighMan
() автор топика
Последнее исправление: HighMan (всего исправлений: 2)
Ответ на: комментарий от HighMan

Я подозреваю, что сеть затыкается, если какая-то программа долго висит на recvfrom, как мой эхо сервер.

Он же сделан за 5 минут на коленке и деревянней дуба.

Во время сетевого бездействия просто висит на recvfrom.

Если что-то пришло на UDP порт, то вертает это отправителю и выводит полученное на экран.

Если же слишком долго на порту не происходило ни какой активности, то сеть виснет и оживить ее можно лишь перезапустив сетевуху, Сначала переводя ее DOWN, потом в UP.

Как это победить???

Конечно можно сделать по уму и вызывать recvfrom или recv по событию (select/poll/epoll), но, боюсь, что наше ПО, которое должно будет крутится на минисистеме сделано так же дубово. Просто ресивы распиханы по потокам и там ждут у моря апельсинов.

HighMan
() автор топика
Ответ на: комментарий от firkax

recvfrom никак с сетевухой не взаимодействует, он только передаёт программе то что уже пришло в ядерный буфер.

Все верно. Я не подумал.

recv/recvfrom работает с буфером.

Тогда, вообще, фигня получается.

Если не запускать мой эхо сервер, то минисистема отзывается на пинги и через час. Больше пока просто не тестировал.

Если же запустить мой эхо-сервер, то минут через 15 бездействия сеть сдыхает.

Сеть всей минисистемы.

HighMan
() автор топика
Ответ на: комментарий от HighMan

Если система это какой-то арм-контроллер то не стоит исключать и дефективное железо. Или плохо совместимое с линуксом.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Если система это какой-то арм-контроллер то не стоит исключать и дефективное железо. Или плохо совместимое с линуксом.

Не-а.

Почти обычный ПК на Atom.

Полновесная система работает нормально. Там мой эхо сервер может годами висеть и ни чего не повиснет.

HighMan
() автор топика
Ответ на: комментарий от HighMan

передало управление сразу /sbin/init рутовой фаловой

Убрать в загрузчике указание на initrd, или у вас initramfs в ядро встроен?

Только модули должны быть в ядре (ФС, дисковое устройство, может какие ещё), и монтирования ФС по UUID не будет, устройство или PARTUUID.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от HighMan

отредактировал bash.cfg что бы он загружал мое творчество или хостовый altlinux.

В смысле grub.cfg?

Ядро от Altlinux или другое? Какой драйвер сетёвки? Может в AltLinux что в параметры модуля прописывается, поэтому работает стабильнее.

Отвал сети и появление после down/up часто проявлялось для гигабитных реалтеков Rtl8169 и подобных. Куча тем, мало работающих решений.

mky ★★★★★
()
Ответ на: комментарий от mky

Какой драйвер сетёвки?
Отвал сети и появление после down/up часто проявлялось для гигабитных реалтеков Rtl8169 и подобных.

Вот кстати плюсану. Вариант разных дровишек у RTL* это известный головняк. Не факт, что в этом проблема у ТС, но тем не менее этот вариант исключать тоже не стоит.

anc ★★★★★
()
Ответ на: комментарий от mky

Доброе утро :)

Полезли интересности…

# lspci -k
00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register (rev 11)
	Subsystem: Intel Corporation Device 7270
	Kernel driver in use: iosf_mbi_pci
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 11)
	Subsystem: Intel Corporation Device 7270
	Kernel driver in use: i915
00:13.0 SATA controller: Intel Corporation Atom Processor E3800 Series SATA AHCI Controller (rev 11)
	Subsystem: Intel Corporation Device 7270
	Kernel driver in use: ahci
00:17.0 SD Host controller: Intel Corporation Atom Processor E3800 Series eMMC 4.5 Controller (rev 11)
	Subsystem: Intel Corporation Device 7270
	Kernel driver in use: sdhci-pci
00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 1 (rev 11)
	Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 2 (rev 11)
	Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 3 (rev 11)
	Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 4 (rev 11)
	Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB EHCI (rev 11)
	Subsystem: Intel Corporation Device 7270
	Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 11)
	Subsystem: Intel Corporation Device 7270
	Kernel driver in use: lpc_ich
00:1f.3 SMBus: Intel Corporation Atom Processor E3800/CE2700 Series SMBus Controller (rev 11)
	Subsystem: Intel Corporation Device 7270
01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
	Kernel driver in use: igb
04:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
	Subsystem: Intel Corporation Device 0000
	Kernel driver in use: igb

Выдал весь выхлоп lspci. Без купюр.

Интересность в следующем: пришел на работу а этот недоПК висит с моей прогой. Система загружена полная. Не мой «огрызок».

Висит наглухо! Ни какой реакции на клавиатуру.

Ну ладно. Семь бед - один RESET.

Загрузилось и… Сети есть, но ее нет!

Поведение в точности как на моем огрызке.

Сетевуха, в полной системе обозначается как enp1s0, в апе. Адрес правильный. Но сеть не пашет. Удалось поднять сеть лишь переведя enp1s0 в DOWN и снова в UP.

Судя по всему железка глюкнутая. Сейчас буду логи смотреть, только что-то мне подсказывает, что я в них ни фигушечки не найду.

PS Что и следовало ожидать - в журнале нет ни каких стремных событий.

Система просто вмерла.

HighMan
() автор топика
Последнее исправление: HighMan (всего исправлений: 2)
Ответ на: комментарий от HighMan

Ну и хорошо. И, в общем то, не важно, ядро кривовато работает или аппаратные глюки, главное, что дело не в вашей проге и не в том, что она запускалась в режиме initrd.

ИМХО, тему можно отметить решёной, ловля глюков этой железяки отдельная тема, но, наверное, мало кто что полезное посоветует.

mky ★★★★★
()
Ответ на: комментарий от mky

Ну и хорошо. И, в общем то, не важно, ядро кривовато работает или аппаратные глюки, главное, что дело не в вашей проге и не в том, что она запускалась в режиме initrd.

Да уж. Обидно, что из-за непргнозируемых аппаратных глюков столько времени и умственных сил теряется.

Вам огромное спасибо за «лидера сеанса». Очень помогли!

ИМХО, тему можно отметить решёной, ловля глюков этой железяки отдельная тема, но, наверное, мало кто что полезное посоветует.

С глюками железки пускай разбираются те, кто их приобретал)

HighMan
() автор топика
Ответ на: комментарий от mky

Хм… Снова приветствую!

Хрень какая-то у меня получается с сетью.

В общем, в минисистеме поднимается сеть и через какое-то время перестает отзываться. Раньше это лечилось перезапуском интерфейса, сейчас оказалось, что ее можно оживлять arping гейтвея.

Судя по всему засада даже не в железке, на которой крутится минисистема, а в роутере, к которому у меня нет доступа.

Тем не менее, полноценные системы как-то ведь работают и у них сеть не падает.

HighMan
() автор топика
Ответ на: комментарий от HighMan

Не знаю, как работают нормальная система, может NetworkManager или что ещё постоянно отправляет ARP-запросы. Или полноценная система что-то пытается скачать, допустим, обновления, а чтобы установить соединение, для определения MAC-адреса шлюза, отправляет arp-запрос.

Если arping работает, повешайте его фоне (запустите с указанием & в конце команды).

mky ★★★★★
()

Соответственно, уже есть в системе сетевые адаптеры (eth0, eth1), к eth0 подключен сетевой кабель.

Это не есть удачно. Ядро назначает имена случайным образом, а если переименовывать udev-ом, то с именами ethN можно нарваться на коллизию при переименовании. И это общедистрибудивно, не только в ALT. Хотя описанная проблема на эту не очень похожа.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от mky

Если arping работает, повешайте его фоне (запустите с указанием & в конце команды).

Это, явно, слишком уж топорное решение.

Куда лучше, примерно раз в минуту, arpingнауть парой пакетов гейтвей.

Кстати, а arping как-то дожет посылать броадкасты, что бы откликнулись все участники сети?

HighMan
() автор топика
Ответ на: комментарий от AS

Это не есть удачно. Ядро назначает имена случайным образом, а если переименовывать udev-ом, то с именами ethN можно нарваться на коллизию при переименовании. И это общедистрибудивно, не только в ALT. Хотя описанная проблема на эту не очень похожа.

В ALT 8 SP чехарда с именами интерфейсов. Скачут как хотят. Что бы добиться прогнозируемых результатов их нужно в udev переименовывать.

HighMan
() автор топика
Ответ на: комментарий от HighMan

слишком уж топорное решение.

То есть, просто висящий в фоне процесс arping, посылающий запрос раз в 30 или 60 секунд это топорное решение, а скрипт, запускающий раз в минуту arping нормальное?

что бы откликнулись все участники сети

Как внесёте подобный пакет в протокол ARP, так arping и сможет его отправлять :)

Броадкастом может обыный ping, только на такие пакеты мало кто отвечает.

mky ★★★★★
()
Ответ на: комментарий от HighMan

В ALT 8 SP чехарда с именами интерфейсов. Скачут как хотят. Что бы добиться прогнозируемых результатов их нужно в udev переименовывать.

Я СП не пользуюсь, но udev в ALT давно делает enp*, если не установлен пакет udev-rule-generator-net. Стоит ли он по умолчанию в СП - не знаю. Если стоит, то там должны правила формироваться для переименования в ethN по MAC, только вот вопрос, какой там udev. А udev-то там, наверное, новее 242-alt1, он уже не может с ethN работать нормально: https://lists.altlinux.org/pipermail/sisyphus/2019-April/367915.html

AS ★★★★★
()