Moin *
Ich kämpfe weiterhin mit IPMI/SOL für den Remote-Zugang zum OS in der zweiten Bootphase.
Was bislang geht via IPMI/SOL:
*BIOS-Setup
*GRUB
Der nächste Schritt will aber nicht, egal was ich tue: Nach der Auswahl innerhalb GRUB sollte die Abfrage nach der LUKS-Passphrase kommen. Dies passiert aber nicht via IPMI, nur auf der lokalen Konsole. Die Konsole von IPMI wird grau und bleibt auch danach so.
Server-Hardware: SuperMicro Servermainboard X9SCL+-F
Server-OS: CentOS 7
Client:
Aufruf:
Diese Dokumentation für die serverseitige Konfiguration habe ich (neben vielen anderen) befolgt:
*https://blog.rot13.org/2020/04/ipmi-serial-console-using-grub-and-systemd.html
*http://0pointer.de/blog/projects/serial-console.html
Man findet viel veraltete Dokumentation im Netz. Weniger für GRUB, aber vor allem mit der durch systemd abgelösten Datei:
/etc/inittab
Ich vermute, es muss an der Parametrisierung des Kernels via GRUB liegen. Alles was in /etc liegt, kann eigentlich nicht damit zu tun haben, weil das ja prinizipiell erst nach der Entschlüsselung sichtbar wird (lediglich /boot-Partition ist unverschlüsselt). Das Problem tritt aber vorher schon auf, bei der Abfrage der Passphrase.
Die produzierte Datei:
Etwas bedrückend ist, dass ich dies auf der selben Hardware vor Jahren schon mal mit CentOS 6 am Start hatte.
Was ich schon probiert habe:
*ttyS[0..3]
*andere Verbindungsgeschwindigkeiten
*alle Redirction-Ziele im BIOS
*Explizite Konfiguration des Devices via systemd mit der passenden Geschwindigkeit (serial-getty@ttySx.service)
Bin am Ende von Energie und Phantasie...
Hat jemand einen Tipp?
TNX
Glückauf, gehrke
Ich kämpfe weiterhin mit IPMI/SOL für den Remote-Zugang zum OS in der zweiten Bootphase.
Was bislang geht via IPMI/SOL:
*BIOS-Setup
*GRUB
Der nächste Schritt will aber nicht, egal was ich tue: Nach der Auswahl innerhalb GRUB sollte die Abfrage nach der LUKS-Passphrase kommen. Dies passiert aber nicht via IPMI, nur auf der lokalen Konsole. Die Konsole von IPMI wird grau und bleibt auch danach so.
Server-Hardware: SuperMicro Servermainboard X9SCL+-F
Server-OS: CentOS 7
Client:
Code:
Name : ipmitool
Version : 1.8.18
Release : 19.fc32
Architecture : x86_64
Aufruf:
Code:
$ ipmitool -H 172.16.10.21 -I lanplus -U ipmi sol info 1
Password:
Set in progress : set-complete
Enabled : true
Force Encryption : false
Force Authentication : false
Privilege Level : ADMINISTRATOR
Character Accumulate Level (ms) : 0
Character Send Threshold : 0
Retry Count : 0
Retry Interval (ms) : 0
Volatile Bit Rate (kbps) : 19.2
Non-Volatile Bit Rate (kbps) : 19.2
Payload Channel : 1 (0x01)
Payload Port : 623
$ ipmitool -H 172.16.10.21 -I lanplus -U ipmi sol activate
Diese Dokumentation für die serverseitige Konfiguration habe ich (neben vielen anderen) befolgt:
*https://blog.rot13.org/2020/04/ipmi-serial-console-using-grub-and-systemd.html
*http://0pointer.de/blog/projects/serial-console.html
Man findet viel veraltete Dokumentation im Netz. Weniger für GRUB, aber vor allem mit der durch systemd abgelösten Datei:
/etc/inittab
Ich vermute, es muss an der Parametrisierung des Kernels via GRUB liegen. Alles was in /etc liegt, kann eigentlich nicht damit zu tun haben, weil das ja prinizipiell erst nach der Entschlüsselung sichtbar wird (lediglich /boot-Partition ist unverschlüsselt). Das Problem tritt aber vorher schon auf, bei der Abfrage der Passphrase.
Die produzierte Datei:
Code:
# cat /boot/grub2/grub.cfg
[...]
serial --speed=19200 --unit=1 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial
[...]
menuentry 'CentOS Linux (3.10.0-1127.13.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1127.13.1.el7.x86_64-advanced-b8977301-01c3-44e6-acf2-16511161081e' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 151a10d5-9161-4f5a-848d-598639c90998
else
search --no-floppy --fs-uuid --set=root 151a10d5-9161-4f5a-848d-598639c90998
fi
linuxefi /vmlinuz-3.10.0-1127.13.1.el7.x86_64 root=/dev/mapper/system-os1 ro crashkernel=auto rd.md.uuid=cbf83815:3d803463:a7724841:e9e0d560 rd.luks.uuid=luks-df284fea-e50b-4431-add4-f01350fc73dc rd.lvm.lv=system/os1 rd.lvm.lv=system/swap console=ttyS0,19200n8 console=tty0
initrdefi /initramfs-3.10.0-1127.13.1.el7.x86_64.img
[...]
Was ich schon probiert habe:
*ttyS[0..3]
*andere Verbindungsgeschwindigkeiten
*alle Redirction-Ziele im BIOS
*Explizite Konfiguration des Devices via systemd mit der passenden Geschwindigkeit (serial-getty@ttySx.service)
Bin am Ende von Energie und Phantasie...
Hat jemand einen Tipp?
TNX
Glückauf, gehrke