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?

★

По поводу пинга — проверь, что адрес не конфликтует ни с кем в сети.

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

По поводу пинга — проверь, что адрес не конфликтует ни с кем в сети.

Проверял. Нет конфликтов.

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

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

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

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

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

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

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

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

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

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

Кстати…

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

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

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

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

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

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

firkax ★★★★★
()

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

anonymous
()

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 ★
() автор топика
Ответ на: комментарий от HighMan

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

firkax ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.