Posts Tagged ‘Festplatte’

Sonntag, 17. März 2024

Wo ist der GRUB Bootloader alles installiert?

Link zu diesem Artikel

Vor einigen Wochen spukte eine SSD in einem meiner physischen Servern. Ich entschied mich, eine neue SSD zu kaufen, den kompletten Inhalt der alten SSD auf die neue SSD zu klonen, und dann die neue SSD als neue Festplatte in den Server einzubauen (die alte SSD wanderte ins Archiv).

Als ich gestern das Debian GNU/Linux auf diesem Server aktualisierte, bemerkte Debian, dass es auf einer neuen SSD lief, und fragte mich, wo ich den GRUB Bootloader überall installieren wollte (/dev/sda, das heisst auf der Festplatte selber, plus /dev/sda1, auf der ersten (Boot-)Partition).

GRUB war natürlich bereits installiert, sonst hätte der Server nach dem SSD-Wechsel nicht gebootet — aber vermutlich war in der GRUB-Konfiguration noch die Referenz auf die alte SSD enthalten und nicht auf die neue.

Überfordert entschied ich mich wie im Dialog angeregt, den Bootloader sowohl auf /dev/sda als auch /dev/sda1 zu installieren. Das sei die sicherste Methode.

Später dann fand ich nach einer mehrminütigen Internetsuche heraus, wie ich bei einem „baugleichen“ Server hätte nachschauen können, wo der Bootloader alles installiert ist:

# debconf-show grub-pc
  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
* grub2/linux_cmdline_default: quiet
  grub-pc/timeout: 5
* grub2/linux_cmdline:
  grub-pc/partition_description:
  grub2/kfreebsd_cmdline_default: quiet
* grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-SanDisk_SDSSDA120G_XXXXXXXXXXXX
  grub-pc/install_devices_failed_upgrade: true
  grub2/force_efi_extra_removable: false
  grub-pc/disk_description:
* grub-pc/install_devices: /dev/disk/by-id/ata-SanDisk_SDSSDA120G_XXXXXXXXXXXX
  grub-pc/kopt_extracted: false
  grub-pc/chainload_from_menu.lst: true
  grub-pc/postrm_purge_boot_grub: false
  grub2/update_nvram: true
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_empty: false
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/hidden_timeout: false

Sprich: Nur auf /dev/sda.

Auf dem Server mit der ausgewechselten SSD schaut es nun halt leider so aus:

# debconf-show grub-pc
* grub-pc/install_devices: /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX, /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX-part1
  grub-pc/install_devices_empty: false
  grub2/force_efi_extra_removable: false
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_failed_upgrade: true
* grub2/linux_cmdline:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/mixed_legacy_and_grub2: true
* grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX, /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX-part1
  grub-pc/timeout: 5
  grub2/kfreebsd_cmdline:
  grub-pc/chainload_from_menu.lst: true
  grub2/update_nvram: true
  grub-pc/disk_description:
  grub-pc/hidden_timeout: false
  grub-pc/kopt_extracted: false
* grub2/linux_cmdline_default: consoleblank=60
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/partition_description:

Sprich: Man sieht, dass der Bootloader sowohl auf die Festplatte, als auch die erste Partition („part1“) installiert wird.

Tags: , , , , , , , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 29. Januar 2021

Welcher Linux-Prozess schreibt am meisten Daten auf die Festplatte?

Link zu diesem Artikel

Ganz einfach, dafür installiert man sich unter Debian GNU/Linux am Besten das Tool iotop:

# apt-get install iotop

Sofort habe ich das soeben installierte Tool gestartet, wurde aus der sich ständig wechselnden Ausgabe aber nicht schlau.

Nach einigen Recherchen im Netz fand ich dann die Startparameter, um die (jedenfalls von mir) gesuchte Diagnose-Funktionalität herbeizuzaubern:

# iotop --accumulated --only --processes
  • --accumulated Summiere alle Lese- und Schreibaktivitäten eines Prozess fortlaufend
  • --only Zeige nur Prozesse, welche auch tatsächlich von der Festplatte lesen oder auf sie schreiben

  • --processes Führe nur Prozesse auf, nicht aber Threads

Nachgelesen unter man iotop.

Anschliessend hilft es vermutlich, mittels Cursor rechts resp. Cursor links diejenige Spalte auszuwählen, nach welcher man die Ausgabe sortieren möchte. Für meinen Anwendungszweck war das natürlich die Spalte DISK WRITE. Die ausgewählte Spalte erkennt man an der Fettschrift sowie dem rechtsstehenden Grösser als.

Tags: , , , , , , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 14. Oktober 2017

Wenn eth0 plötzlich enp1s0 oder ähnlich kryptisch heisst

Link zu diesem Artikel

Heute habe ich einen meiner Lenovo-„Server“ ausgetauscht: T400 raus, T420 rein. Dabei habe ich die SSD vom alten Server in den neuen Server eingebaut — bei Windows ein Ding der Unmöglichkeit, bei Linux: Läuft bei mir (fast).

Leider gab es ein gravierendes Problem, was die Downtime etwas verlängert und an meinem Ehrgeiz gekratzt hat: Die Netzwerk-Interfaces kamen nicht hoch, weshalb das Gerät ohne Intra- und Internet-Verbindung dastand.

Dank Laptop-Tastatur und -Bildschirm fiel immerhin das Debugging leicht.

Die Ausgabe von ifconfig zeigte, dass nur das Loopback-Interface vorhanden war. Was zum Teufel? Den Ethernet-Netzwerkanschluss sah ich mit meinen eigenen Augen vor mir, ein Kabel war eingesteckt und er blinkte auch fröhlich vor sich hin.

# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 184819  bytes 33744666 (32.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 184819  bytes 33744666 (32.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Mit dem Befehl ip a dann die Gewissheit, dass die erwarteten Schnittstellen auch tatsächlich da waren:

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.10/24 brd 10.10.10.255 scope global enp1s0
       valid_lft forever preferred_lft forever
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Wie sich herausstellte, hiess auf dem T420 die Netzwerkschnittstelle nicht wie erwartet und üblich eth0, sondern enp1s0.

Der Grund (bitte nicht lachen): Predictable Network Interface Names. Verursacht durch die Datei /etc/udev/rules.d/70-persistent-net.rules, welche bei der Installation auf dem T400 erstellt worden war. Linux fand die darin definierten Interfaces auf dem T420 nicht mehr.

Die Lösung des Problems fand sich in einem Benutzerforum zum Thema How to rename network interface in 15.10?.

An der Originaldatei …

...
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="11:11:11:11:11:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
...

… nahm ich folgende Anpassung vor:

...
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:00:00:00:00:00", NAME="eth0"
...

Wichtig: 11:11:11:11:11:11 ist die MAC-Adresse des Ethernet-Interfaces auf dem T400, 00:00:00:00:00:00 ist die MAC-Adresse des Ethernet-Interfaces auf dem T420. Als ich zuerst nur die MAC-Adresse geändert habe, kam die Netzwerkschnittstelle nicht hoch. Erst die Verschlankung des Eintrags auf die obige Form funktionierte: Nach dem nächsten Reboot war eth0 wieder vorhanden und alle Netzwerkdienste kamen hoch.

Nachtrag

Die Herleitung des kryptischen Namens ist hier erläutert: Why is my ethernet interface called enp0s10 instead of eth0?.

enp1s0 bedeutet also:

  • en Ethernet
  • p1 Bus (hier: 1)
  • s0 Slot (hier: 1)

Nachtrag 2

Auf einem jungfräulichen Debian 11 Bullseye System musste ich gestern /etc/udev/rules.d von Hand erstellen.

Dementsprechend fehlte auch /etc/udev/rules.d/70-persistent-net.rules. Obwohl im Internet stand, dass man mit dem Befehl

# /lib/udev/write_net_rules

die benötigte Datei erstellen könne, fehlt auf meinem System dieser Befehl (ich konnte das Script auch in keinem Debian-Paket finden — komisch). Ich erstellte deshalb /etc/udev/rules.d/70-persistent-net.rules kurzerhand von Hand, startete das System neu, und es funktionierte.

Übrigens: Die Verwendung deterministischer Interface-Namen könnte man auch mit einem Kernelbefehl in /etc/sysctl.conf verhindern: net.ifnames=0

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen