Dotaz: Více sériových konzolí (kernel/boot)?

[Petr Tomášek]

Zdravím!

Potřeboval bych na jednom stroji, aby poskytoval více seriových konzolí - tj. konkrétně aby na ttyS0, ttyS1 i ttyS2 bylo možné se připojit na konzoli.

Po bootu mi to funguje v pořádku, v /etc/inittab mám:

# Terminal on serial lines...
#
T0:23:respawn:/sbin/getty -8 -h -L ttyS0 115200 vt220
T1:23:respawn:/sbin/getty -8 -L ttyS1 115200 vt220              # COM2 - Rx/Tx only, no hw-flow!
T2:23:respawn:/sbin/getty -8 -h -L ttyS2 115200 vt220

A když spustím na druhé mašině minicom, tak se normálně přihlásím a vše funguje ok.

Potíž je ale s jádrem (a s BIOSem, ale ten upravit by mohlo být snadné), když dám do lilo.conf:

append="console=ttyS0,115200 console=ttyS1,115200 console=ttyS2,115200"

tak to bohužel používá konzoli jen na ttyS. V dmesg to taky vypíše jen:

[    0.000000] Kernel command line: auto BOOT_IMAGE=linux ro root=LABEL=*censored* console=ttyS0,115200 console=ttyS1,115200 console=ttyS2,115200
...
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [ttyS0] enabled

Což asi bude tím, že i v dokumentaci píšou:

Note that you can only define one console per device type (serial, video).

Co tedy s tím? Docela bych to potřeboval, jednak kvůli hláškám jádra při bootu, jednak pro případ, že by se stroj zasekl při bootu a chtěl do rootovské konzole. Existuje nějaký trik? Nebo patch do jádra? Nebo páka na to, aby si to Linus konečně opravil? [*verzweifelt*]

Odpovědi

[NN]

Jen bokem, nemel by byt v /inittab jako id S0,S1,S2 misto T0,T1,T2 viz man:

 traditionally, for getty and other login processes, the value of the id field is kept the same as the suffix of the corresponding tty

=> ttyS0..

Imho. proc jedna konzole nestaci?

[Petr Tomášek]

Jen bokem, nemel by byt v /inittab jako id S0,S1,S2 misto T0,T1,T2 viz man

Může být, já jsem jen upravil to, co tam bylo už z distribuce, nad těmito konvencemi jsem nekoumal a fungovalo mi to.

Imho. proc jedna konzole nestaci?

Jedna konzole je pro připojní externího PC (laptopu).

Jsou to dva stroje (PC Engines APU) ve funkci domácího routeru/serveru zapojené tak, aby v případě výpadku bylo možné, aby jeden zastal funkci druhého. Jsou v jedné skříni a interně mají vzájemně propojené ttyS2 <-> ttyS3 (v TTL 3.3V logice), tak aby bylo možné se na dálku vrtat např. v konfiguraci sítě bez rizika, že to člověk už neopraví.

Ještě plánuji připojit raspberryPi, jehož hlavní funkcí bude resetovat obě desky a v případě nutnosti do nich přes SPI nahrát novou verzi BIOSu. Vzhledem k tomu, že desky mají vyvedený ttyS1 na headeru v TTL 3.3V logice, tj. stejně jako RPi, se přímo nabízí ještě pro sichra mít konzoli přístupnou alespoň na jedné desce z toho RPi.

Ale to už by byla jen taková třešnička. Důležité je, aby byl přístup na konzoli vždycky z toho druhého stroje, a pak přes klasický RS232, co ty desky mají vyvedený ven, aby když tam člověk bude fyzicky, aby nemusel všechno rozebírat a shánět převodník na 3.3V TTL logiku..

Jedná se o síť v rodině, kterou mám >500km daleko a chci ji udělat co nejvíce "idiotensicher", aby se s tím na dálku dalo něco udělat v případě výpadků (těch teď bylo několik vinou kolísání napětí v síti, vyřešil jsem to koupí UPS, ale stejně chci co největší redundanci...)

[MM]

Ano, při bootu lze jen 1 konzole,

určitě by šel výstup TTYS0 hardwarově "rozdvojit" a poslouchat 2ma sériovkami na tom samém výstupu z desky(drátě), ale s opačným směrem by byl problém, praly by se vysílače, tam to nejde, jedině přepínač...

[Petr Tomášek]

No, nevím proč by se softwarová chyba měla řešit hardwarovou ochcávkou, to nedává smysl...

[NN]

To neni chyba, proste by se ta seriova komunikace prala mezi sebou. Tipuju, ze sice vytvoris nekolik seriovych rozhrani, ale budou se navzajem blokovat..

[Peter Golis]

Zaujímalo by ma koľko by stál arduino multiplikátor portov, alebo prevodník seriák na ethernet. I keď takáto hračka nenahradí vzdialenú konzolu aké sú v serveroch.

[Petr Tomášek]

Je to chyba.

Zvlášť, když paralelně vedle sebe můžou být konzole na tty* a konzole na ttyS*. Ty se neperou?

[Vantomas]

Nejsem na to odborník, ale dokážu si představit, že celý problém bude někde v tom, že jak se tahle rozhraní inicializují hrozně brzo, aby se tam mohl zobrazovat výstup z kernelu, tak to může mít hromadu omezení, které by nebylo úplně snadné obejít.

[Peter Golis]

Tesne vedľa. Ono je to obedzenie prameniace z HW komunikácie medzi jedným sériovým portom jedného počítača, a sériovým portom dvoch naraz pripojených terminálov. Jednoduchá rozdvojka na COM porty zo svojej podstaty nebude moc fungovať. COM, teda RS-232 bolo navrhnuté na prepojenie dvoch zariadení.

Iné by to bolo, keby mal dva COM porty. Či už priamo na doske, alebo cez USB.

[Vantomas]

Ale tady trošku dochází k míchání jablek a hrušek. Návrh byl, že se má prostě na jeden RS232 port připojit dvě zařízení, která budou koukat na výstup jádra. Tazatel na to řekl, že nechápe, proč by měl chybu v jádře řešit hardwarovou obezličkou. A vy teď tady tvrdíte, že to není žádná chyba, že je to vlastnost RS232 protokolu.

Jde o to, že tazatel chybou nazval neschopnost jádra vypisovat early messages na dva různé RS232 porty, nikoliv to, že nelze mít dvě zařízení na jednom a témže RS232 portu!

[Peter Golis]

Áno. Otázka bola ako multiplikovať výstup jadra na viacej sériových konzolí. Odpoveďou bolo že jedna bežná (RS232) sériová konzola nepripojí viac ako jeden terminál. Reagoval som na to, že odpoveď je korektná, ale nie je na pôvodnú otázku.

A ohľadne pôvodnej otázky, tak by to malo čiastočne ísť ak zabezpečí že na jednej RS232 konzole prepojí len dva endpoonity. Nie jeden počítač s dvoma terminálmi cez jeden kábel divne zletovaný.

Viac info je v štandardnej dokundamentácii:

You can specify multiple console= options on the kernel command line. Output will appear on all of them. The last device will be used when you open /dev/console.

Takže výstupy by mal uvidieť na všetkých a getty mu už funguje. Ale pripisovanie cez /dev/console (napr cez syslogd) zapíše len do poslednej.

[Michal Kubeček]

Jenže o kousek níž je také

Note that you can only define one console per device type (serial, video).

Ale takhle z hlavy nevím, jestli je za tím nějaký hlubší důvod nebo je to jen důsledek implementace. V každém případě by to stejně nebylo moc praktické, už jedna sériová konzole může někdy nepříjemně zdržovat.

[Peter Golis]

A takmer na konci je rok 2000, odkedy sa toho mohlo veľa zmeniť.

Miimochodom, ajtak mu to nenahradí funkcionalitu vzdialeného prístupu známeho zo serverov. A na bežné problémiky je tu bežný watchdog napojený na reset.

[Grunt]

A co takhle se mrknout do early_serial_console.c? Já si myslím že je to vcelku jasné. Outb() jsem neviděl už ani nepamatuju a jestli se nepletu tak je to nízkoúrovňový zápis přímo kamsi na porty, ne? Kam se se co zapisuje tomu nerozumím, ale kdybych měl hádat moc daleko od BIOSu to mít nebude. early_serial_init() jednoduše inicializuje jeden port, to je celé. Proto výstup na jednom sériovém portu.

[Grunt]

A ještě se dívám, že ono je to popsané i v dokumentaci:

The Linux kernel has 2 general types of console drivers. The first type is assigned by the kernel to all the virtual consoles during the boot process. This type will be called 'system driver', and only one system driver is allowed to exist. The system driver is persistent and it can never be unloaded, though it may become inactive.

Ještě něco nejasného? Soudruh Grunt vždy rád vysvětlí a zpříjemní den

[Petr Tomášek]

Pochopitelně že je na tom nejasného vše: proč to naprogramovali tak prasácky.

[Grunt]

Normálně bych řekl pošli patch, ale když se na to dívám tak spíš popřeju mnoho štěstí s patchem. Dle mého názoru by to byl zbytečný overkill vymýšlet nějaké kopírování a otázka je jestli vůbec možné inicializovat víc UART pomocí psaní do portů v brzké části bootu. Já bych se na to vykašlal.

[k3dAR]

btw: jednoho by napadlo na server pouzit desku s IPMI

[pc2005]

Protože ten early boot JE požadavek na prasárnu, chceš logovat ještě před inicializováním subsystémů. Pokud to chceš dělat čistě, tak si zapoj JTAG a dumpuj si log buffer v RAM.

[Grunt]

chceš logovat ještě před inicializováním subsystémů

Zde si dovolím malé poupravení: Subsystémy inicializované jsou. BIOSem. Doporučuju projít si kód ve složce arch/x86/boot (není toho moc). V podstatě veškerý kód co tam je se umisťuje před rozbalení a spuštění hlavního jádra (je to vlastně nekomprimovaná přímo spustitelná hlavička vmlinuxu). Úplně nejúchvatnější je ovšem main.c:

void main(void)
{
	/* First, copy the boot header into the "zeropage" */
	copy_boot_params();

	/* Initialize the early-boot console */
	console_init();
	if (cmdline_find_option_bool("debug"))
		puts("early console in setup code\n");

	/* End of heap check */
	init_heap();

	/* Make sure we have all the proper CPU support */
	if (validate_cpu()) {
		puts("Unable to boot - please use a kernel appropriate "
		     "for your CPU.\n");
		die();
	}

	/* Tell the BIOS what CPU mode we intend to run in. */
	set_bios_mode();

	/* Detect memory layout */
	detect_memory();

	/* Set keyboard repeat rate (why?) and query the lock flags */
	keyboard_init();

	/* Query Intel SpeedStep (IST) information */
	query_ist();

	/* Query APM information */
#if defined(CONFIG_APM) || defined(CONFIG_APM_MODULE)
	query_apm_bios();
#endif

	/* Query EDD information */
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
	query_edd();
#endif

	/* Set the video mode */
	set_video();

	/* Do the last things and invoke protected mode */
	go_to_protected_mode();
}

Inicializace sériové konzoly probíhá jako druhý bod. Tedy před tím než se vůbec zkontroluje jestli je jádro možné spustit na daném CPU, před inicializací klávesnice, VGA módu, před přepnutím do chráněného režimu a před tím než se jádro rozbalí a vlastně spustí. Sem skáče GRUB a v této fázi se toho nedá dělat o moc víc než v běžném DOSu. Vlastně jen volat BIOS (což je přesně co se děje - viz bioscall.S a ano jsou tu segmenty napsané v assembleru!) a přímo zapisovat na porty. Takže otravovat že nejsou inicializované dva sériové porty…hele asi to půjde ale případným zájemcům bych popřál mnoho štěstí ve vlastnoruční implementaci i když bych byl Linus který to očividně psal

[pc2005]

Subsystémy jako usb nemusí být inicializovány BIOSem a pokud BIOS inicializuje USB mass storage, tak to ještě neznamená, že bude umět inicializovat nějaký obskurní USB→UART čipset z číny. Každopádně tak jako tak si linux inicializuje usb až později (dokonce na mém embedded počítači chce kernel mountovat rootfs ještě před inicializací usb mass storage). A pokud zavrhneme uart na usb, tak pořád jsou PCI řadiče a linux je může pomocí voleb pci=pcie_scan_all,realloc inicializovat. Na x86 na to potřebuje znát rozložení RAM, mít správně nastavený MTRR apod.

[Petr Tomášek]

Ovšem v našem případě sedí ten UART na LPC a je inicializován BIOSem. Fyzicky není problém mít klidně 4 konzole.

[pc2005]

main() není naprogramovaný jen pro tvoují konkrétní hardwarovou konfiguraci

[Petr Tomášek]

No a?

Takže kvůi tomu, že to pro některé hardwarové konfigurace nejde, tak to zabalíme rovnou pro všechny?

To je hodně blbá výmluva.

[Petr Šobáň]

Panebože a kde je problém? Pokud jseš takový odborník tak si to dodělej a dopiš....

Jinak podle mě je to absolutní blbost....

Nikdo nebude přepisovat kernel pro jedno použití ve specifickém nasazení!

[k3dAR]

a vazne si myslis ze to pro PetuT nikdo zadarmo nenapise??? aby si PetaT preci nemusel porizovat KVM-over-IP (ktere mu prijde trahe), nebo pridavat dropbear/ssh do initramfs kdyz mu staci vedet co se deje az pri/po pripojovani rootfs (na coz je asi linej

[Petr Tomášek]

Popravdě řečeno, požadavek není ani tak na "early boot console", mě stačí, abych na konzoli vidět, jak proběhne připojení root filesystemu a co to udělá dále...

[k3dAR]

v tom pripade si dej dropbear do initramfs

[Grunt]

Přesně tak. Ono to do early userspace nenaběhne o moc později než se opravdu inicializují všechny ty UARTčka (pokud není dokonce ovladač jako jaderný modul v initrd!).

[Petr Tomášek]

Hm, tohle by možná vysvětlovalo, proč mi to nefungovalo, když jsem snažil nastavit ttyS2 jako konzoli (akorát já to dal do parametru console=, tady se má jednat o earlyprintk=:

		} else if (!strncmp(arg + pos, "ttyS", 4)) {
			static const int bases[] = { 0x3f8, 0x2f8 };
			int idx = 0;

			/* += strlen("ttyS"); */
			pos += 4;

			if (arg[pos++] == '1')
				idx = 1;

[Jose]

Převeď si tu RS232 na RS485 a na ní můžeš pověsit v podstatě libovolně terminálů.

[Grunt]

Tohle ale není vůbec špatný nápad. Fungovalo by to přes nějaký modem? Já jen dodám že jsem právě objevil fakt že SysRQ funguje i přes sériovou konzoli (v životě jsem to neviděl fungovat na vlastní oči), tzn. nějakou kartu s modemem který není možné rozštelovat, GRUB s natvrdo zadrátovaným výstupem na sériovou konzoli a víceméně má člověk stroj který nemůže dostat do stavu kdy by s ním nešlo na dálku pracovat. Musel by jedině zpanikařit kernel nebo něco takového.

[Jose]

Myslíš něco takového :

local Linux serial RS232 -> RS232toTCPIP -> Internet -> Remote TCPIPterminal

jako RS232toTCPIP se dá použít třeba https://www.papouch.com/cz/shop/product/gnome232-prevodnik-ethernet-rs232/

[Grunt]

Yup. Přesně to myslím. Masakr.

[Peter Golis]

Tá cena sa naozaj za posledných 10 rokov nezmenila. V čom je to lepšie ako prevodník RS232 na WiFi a 5$ z Číny?

[Jose]

Že od Papoucha je to odskoušené průmyslové řešení na které ke spoleh ?

[Peter Golis]

Desať rokov stará technológia za nezmenenú cenu. To je pri opisovanom nasadení pre tri stroje drahšie riešenie ako KVM over IP. A pochybujem že je to aj menej poruchové. Ale keby som chcel riešiť opisované hračky, tak si tam flusnem watchdog na reset.

[NN]

Osobne jsem chtel jit do WIZ110SR a krabicka na 3D tiskarne, ale k realizaci uz nedoslo.

[Grunt]

Jako výstup můžeš použít pouze jednu konzolu takže to console= console= console= je úplně zbytečné a i kdyby ne, tak jádro inicializuje při bootu pouze jedno sériové rozhraní. Celý problém. Opravovat není co. Není to bug.

[Petr Tomášek]

Jako výstup můžeš použít pouze jednu konzolu

Což je přesně ten bug...

[Grunt]

To je fíčura, ne bug

[Petr Tomášek]

Výmluva

[Aleš Kapica]

Podle stránky o sériové konzoli na kernel.org to není pravda. Záleží pouze na tom, jak to jádru předáš.

Navíc jak jsem zjistil, záleží na tom jaký použiješ zavaděč. Každý se chová krapet jinak. Zatím jsem ale ve fázi kdy zjišťuji jakými parametry lze výchozí konfiguraci změnit. Konkrétně, GRUB2 zavedený přes PXE zcela evidentně při zavádění jádra (přes UEFI!) posílá výstup kamsi, nevím zatím kam. Tím pádem když dáš break a zůstaneš v ramdisku, je pro tebe konzole nedostupná - na monitor se dostane výskup až ve fázi, kdy už je všechno upečené, a Xorg při spouštění detekuje monitory.

[Grunt]

Já už jsem to pochopil. On je to jedna konzole na druh zařízení, tzn. ono to duplikovat očividně umí… testnu to radši nech tu nemlátím prázdnou slámu.

[pc2005]

Asi by to šlo udělat, že se printk data odešlou postupně na všechny ttyS. Žádný problém nikoho zatím nedonutil aby to implementoval. Navíc boot zprávy přes uart stejně budeš potřebovat hlavně při debugingu a víc aktivních výstupů = víc random přerušení = víc heisenbugů.

[Grunt]

Mě napadnul ještě jeden velmi solidní overkill. Netconsole. Nejsem si úplně jistý, ale to myslím jde kombinovat s příkazem pro konzolu, tedy mít standardní I/O přes vzdálenou sériovou konzolu (jednu!) a zároveň zachytávat zprávy přes TCP/IP (ty bude kopírovat). Má to jeden háček. Velmi custom kernel se všema zabudovanýma driverama včetně stacku a netconsole přímo v jádře. A z toho pramení zase omezení typu natvrdo nastavená IP (parametr při bootu), nezabezpečené UDP zprávy přes půlku internetu které se musí někde odchytávat…no hodně štěstí. Najednou ta karta pro vzdálenou správu jak tu kdosi navrhoval není zas tak špatný nápad. Ale fungovat by to mělo, kritické zprávy přes normální sériovou konzolu a netconsole přivádí kartu k životu hodně brzo, takže převážná většina bootu už by měla frčet přes síť.

[Petr Tomášek]

Chci vidět IPMI kartu do PC Engines APU...

[k3dAR]

pokud mas desku co nema IPMI onboard a/nebo do ktere nelze pridat, muzes pripojit KVM-over-IP ktere je nezavisle na HW

[Petr Tomášek]

Jasně, takže místo toho, abych proprojil desky uvnitř casu pomocí UARTu několika káblíky (a řešil se problém tam, kde je, totiž v prasácky napsaném jádře), tak bych podle tebe měl kupovat drahý KVM-over-IP a předpokládat, že je to natolik dobře zabezpečený, abych to mohl vystrčit do internetu??? Ne, to je opravdu blbost nejvyšší..

Navíc by se to KVM stejně asi už do racku nevlezlo

[Grunt]

Spíš bych se na to vykašlal. Je to embedded zařízení, ne raketový odpalovač. Jestli se dobře dívám, má to jen jeden integrovaný DB-9. Po tom nikdo nemůže chtít zázraky.

[Petr Tomášek]

Díváš se blbě.

Má to v sobě „Super-IO“ čip Nuvoton NCT5104D (přes LPC sběrnici), který umí 4 (slovy čtyři) UARTy: Jeden z nich (ttyS0) to má vyvedeno jako RS-232 na „zadním“ panelu, druhý (ttyS1) je vyvedený v 3.3v logice na speciálním headeru na desce (ovšem z nějakého nepochopitelného důvodu jenom signály Rx/Tx), a ttyS2 a ttyS3 jsou vyvedeny na "GPIO"-headeru rovněž v 3.3v logice ovšem pokaždé v "plné polní", tedy všech 8 signálů co RS-232 má (akorát to má jiné úrovně)!

Se správnou verzí BIOSu (resp. CoreBootu) druhé dva porty také linux bez problému nadetekuje a jedou jak po másle. Viz výsek z dmesg:

[    2.569637] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    2.598223] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[    2.626809] serial8250: ttyS2 at I/O 0x3e8 (irq = 4, base_baud = 115200) is a 16550A
[    2.655405] serial8250: ttyS3 at I/O 0x2e8 (irq = 3, base_baud = 115200) is a 16550A

Tady se není na co vykašlávat. Připojit se po dokončeném bootu na konzoli (getty) není problém, chápeš to?

Jedinej problém je s hláškama a konzolí při bootu, jinak vše funguje, jak má...

[PetebLazar]

Ad změny síťové konfigurace: Co využít v cronu naplánovaného rollback plánu (automatické obnovení původních konfiguračních souborů před provedenými změnami podle nutnosti s/bez restartu)? Pokud se vzdáléná konfigurace nezdaří podle plánu a plán v cronu se ručně na dálku včas neodstaví, tento se automaticky provede, obnoví spojení a může se tak začít s druhým pokusem.

[Petr Tomášek]

A když mezitím vypadne proud?

[PetebLazar]

Ten rollback skript může být naplánován na několik časů dopředu s rostoucím časový odstupem (časově nejbližší po obnově napájení zabere). V případě úspěšné konfigurace se rollback plány včas zruší.