Hop là, un petit retour d'expérience pour ceux qui aiment voir booter leur OS en console série (via IPMI par exemple).
Exit inittab, systemd fait le boulot !
sortie pour grub et le noyau
editer /etc/default/grub
changer : GRUB_CMDLINE_LINUX_DEFAULT="quiet nmi_watchdog=0"
en : GRUB_CMDLINE_LINUX="console=tty0 console=ttyS1,9600"
ajouter à la fin :
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --unit=1 --speed=9600 –stop=1"
lancer : update-grub
RQ : 9600 c'est bien, ça évite la renégociation de vitesse avec les cartes iDRAC et donc la perte de console
console sur port série
cp /lib/systemd/system/serial-getty@.service \
/etc/systemd/system/serial-getty@ttyS1.service
sed -i "s|^ExecStart=.*$|ExecStart=-/sbin/agetty 9600 %I $TERM|g" \
/etc/systemd/system/serial-getty@ttyS1.service
chmod 644 /etc/systemd/system/serial-getty@ttyS1.service
systemctl --system daemon-reload
systemctl start serial-getty@ttyS1.service
systemctl enable serial-getty@ttyS1.service
systemctl status serial-getty@ttyS1.service
# Merci.
Posté par Naabster . Évalué à 4.
Venant de faire l'acquisition récente d'une carte avec IPMI destinée à un NAS, je ne peux que te remercier pour le retour d'expérience.
Encore merci.
[^] # Re: Merci.
Posté par ghusson (site web personnel) . Évalué à 1.
Heureux que ça serve :-)
# ttyUSB0?
Posté par Benjamin Henrion (site web personnel) . Évalué à 3.
Que faudrait-il pour pouvoit avoir une console serie sur ttyUSB0?
[^] # Re: ttyUSB0?
Posté par KiKouN . Évalué à 2.
C'est un peu dangereux. Il suffit de mettre un périphérique USB qui utilise un port série pour avoir un comportement bizarre. Il est préférable d'utilisé en vrai port série pour cela. Cela n'évite pas les comportements bizarre, mais avoir une console sur un port série, c'est plus évident.
J'ai notamment eu le cas avec des switchs. La première fois, sur le port série, j'ai vite compris pourquoi je n'avais pas un accès convenable au switch. La deuxième fois, ce fut pas si évidant de comprendre qu'il y avait une console sur le port série USB malgrès la première expérience.
[^] # Re: ttyUSB0?
Posté par ghusson (site web personnel) . Évalué à 1.
C'est sûr que c'est pas génial d'utiliser du série/USB mais tu n'as peut être pas le choix ?
Côté grub, je ne sais pas si des drivers sont présents. A voir.
Côté kernel, je ne sais pas comment adresser un port série USB au boot. A voir.
Pour l'OS, j'imagine qu'il faut remplacer le ttyS1 du howto avec systemd par ttyUSB0 ?
[^] # Re: ttyUSB0?
Posté par benja . Évalué à 2. Dernière modification le 11 avril 2016 à 20:36.
Pour la partie user-space, de la même manière que la(es) solution(s) proposée(s). I.d. en ajoutant un service serial-getty@ttyS1.service dans systemd.
Pour la partie kernel, je crains que ça ne soit pas possible. De plus, la pile USB est démarrée bien trop tard dans l'initialisation du noyau pour que cela soit intéressant. À ma connaissance, il n'est pas non plus possible de basculer la console noyau une fois le système démarré.
Un autre problème est qu'un pilote USB est autrement plus complexe: il y a plusieurs couches d'abstraction, le pilote du contrôleur usb doit encore pouvoir répondre au interruptions, etc. Contrairement au mode série où c'est un contrôleur matériel qui s'occupe du transfert des données (cela fonctionne toujours dans une certaine mesure avec les interruptions levées) et donc cela a beaucoup plus de chance de fonctionner lorsque le noyau se plante.
Ce qui se fait de mieux après la console série au niveau de la résilience, c'est la console via firewire et via réseau, mais je ne suis pas certains que ces fonctionnalités existent encore pour les noyaux récents.
# Plus propre
Posté par Prosper . Évalué à 7. Dernière modification le 11 avril 2016 à 16:54.
Systemd permet d'"overrider" une unit.
dans l'éditeur mettre les lignes suivantes qui permet de substituer la ligne ExecStart
ça crée en fait le fichier /etc/systemd/system/serial-getty@ttyS1.service.d/override.conf
puis
[^] # Re: Plus propre
Posté par ghusson (site web personnel) . Évalué à 2.
Oui c'est une manière de voir les choses.
J'utilise un service customisé c'est peut être un peu abusé pour changer un paramètre. Et moins pérenne pour les upgrades.
Mais au moins on peut le retrouver facilement (cas d'un admin novice en systemd - comme moi :-).
Il faudra que je teste à l'occasion pour me faire une meilleure idée.
En tout cas merci pour l'info !
[^] # Re: Plus propre
Posté par benja . Évalué à 1.
Normalement il ne faut rien faire de plus que l'argument console= via le bootloader, en tout cas chez-moi-ça-marche(tm), en 115200 bauds du moins. Avez-vous essayé en 9600 ?
Cf. systemd-getty-generator(8) et https://github.com/systemd/systemd/blob/70a399c43a293cc4864c4e9421e265a64305cdc5/src/getty-generator/getty-generator.c#L189 .
[^] # Re: Plus propre
Posté par ghusson (site web personnel) . Évalué à 1.
Eh bien dis donc, on dirait bien que je me suis embêté pour rien ;-)
A valider, mais c'est séduisant !
[^] # Re: Plus propre
Posté par claudex . Évalué à 4.
On retrouve les fichiers utilisés dans le status du service, par exemple:
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Plus propre
Posté par ghusson (site web personnel) . Évalué à 2.
Ok, c'est bon à savoir, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.