Grub Rescue nach Update Kernel 4.19.0-13-amd64

[oln]

Hallo Forum,
ich habe ein Server mit Debian Buster und laufendem Kernel 4.19.0-12 und Legacy-Installation.
Wenn ich nun ein das Metapaket linux-image-amd64 installier, dann bekomme ich ja immer den neusten Kernel.
Beim Update auf den o.G. Kernel habe ich massieve Probleme. Ich lande dann immer im Grub rescue Modus.
Dort bekomme ich auch nicht den Kernel zum laufen.
Meine Rettung ist dann, von einem USB-Stick zu booten und dort im Rescue-Modus den Kernel wieder runter zu schmeißen und dann vom USB-Stick Grub neu zu installieren.
Wenn ich versuche Grub aus dem Orginal System zu installiern, dann lande ich trotzdem im Grub rescue.
Leider weiß ich nicht mehr weiter. Kann sich einer daruf einen Reim machen und mir auf die Sprünge helfen?

Mir sind einige Sachen aufgefallen.
Ausgabe von fdisk:

Code: Alles auswählen

Device          Start        End    Sectors  Size Type
/dev/sda1        2048       4095       2048    1M BIOS boot
/dev/sda2        4096 7745482751 7745478656  3,6T Linux filesystem
/dev/sda3  7745482752 7811889151   66406400 31,7G Linux swap

Was macht da sda1?
Den Bootloader habe ich in sda installiert.

Danke im Voraus.

Mfg Ole

[smutbert]

BIOS Boot ist eine eigene Partition zur Aufnahme eines Teil des Bootcodes und sollte bei mbr/msdos-partitonierten Datenträgern nicht notwendig sein.

Wenn du die ganze Ausgabe von

Code: Alles auswählen

fdisk -l /dev/sda

posten würdest, könnten wir sehen auf welche Art partitioniert wurde (wahrscheinlich mbr/msdos, aber dann wäre tatsächlich die Existenz der BIOS Boot Partition merkwürdig).

Dein Problem liegt jedenfalls weniger am Kernel als vielmehr am Bootloader/grub. Wenn du im Rescue Modus von grub landest, dann wurde ja noch nicht einmal versucht einen Kernel zu laden.

[oln]

Moin,
hier die Komplette Ausgabe von fdisk:

Code: Alles auswählen

[root@saturn ~]# fdisk -l /dev/sda
Disk /dev/sda: 3,7 TiB, 3999688294400 bytes, 7811891200 sectors
Disk model: MR9363-4i
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 262144 bytes
Disklabel type: gpt
Disk identifier: F85273BF-212D-4109-98AC-0BAD8F5263F1

Device          Start        End    Sectors  Size Type
/dev/sda1        2048       4095       2048    1M BIOS boot
/dev/sda2        4096 7745482751 7745478656  3,6T Linux filesystem
/dev/sda3  7745482752 7811889151   66406400 31,7G Linux swap

Merkwürdiger Weise habe ich schon öffter ein Kernelupdate durchgeführt. Da gab es dann keine Probleme. Erst nach dem Kernelupdate zu 4.19.0-13.
Das es nicht am Kernel liegt, war mir schon klar. Aber dann muss es am Paket liegen.
Die Frage bleibt ja, wie kann ich das retten?
Der Server ist produktiv und steht 650km entfernt. Somit ist eine Neuinstallation erst einmal ausgeschlossen.

[smutbert]

gpt und eine BIOS Boot Partition ist ein übliches Szenario, daran sollte es also nicht liegen.

Das hier

[...]
ich habe ein Server mit Debian Buster und laufendem Kernel 4.19.0-12 und Legacy-Installation.
Wenn ich nun ein das Metapaket linux-image-amd64 installier, dann bekomme ich ja immer den neusten Kernel.
Beim Update auf den o.G. Kernel habe ich massieve Probleme. [...]

klingt so als wäre das Metapaket davor gar nicht installiert gewesen, was an sich ja schon ungewöhnlich wäre

Das es nicht am Kernel liegt, war mir schon klar. Aber dann muss es am Paket liegen.
Die Frage bleibt ja, wie kann ich das retten?

Ich glaube auch gar nicht, dass es am Kernelpaket liegt, sondern an grub, auch wenn ich fürs erste keine Idee habe, was da von heute auf morgen schief laufen kann.

War das Metapaket vorher tatsächlich nicht installiert, und wenn weißt du warum es das nicht war?
Hast du an dem System irgendetwas gemacht?

Zur Übersicht wäre auch noch

Code: Alles auswählen

lsblk -rf

ganz interessant.

Und ein Check und gegebenenfalls eine Reparatur des Dateisystems wären vielleicht auch nicht schlecht, entweder mit »touch /forcefsck« und einem Reboot (wobei ich iegentlich nicht weiß ob Fehler da repariert werden, ob nachgefragt wird oder ob Fehler nur berichtet werden) oder vom System vom USB-Stick aus.
(Fehler im Dateisystem können grub locker lahmelegen, weil grub ja aus dem Dateisystem Module und die Konfigurationsdatei laden muss, bevor es überhaupt in die Verlegenheit kommen kann einen Kernel laden zu wollen.)

Besonders wenn Dateisystemfehler gefunden werden, aber auch sonst könntest du den Zustand der Platte/SSD mit den smartmontools prüfen. Oder ist das ein RAID-Controller?
(Hardware-RAID-Controller sind mir suspekt und ich habe das Gefühl, dass sie eine beliebte Fehlerquelle sind – wie man feststellt ab an dem Ende alles in Ordnung ist, weiß ich nicht.)

[oln]

Hallo und danke für die Antwort.

klingt so als wäre das Metapaket davor gar nicht installiert gewesen, was an sich ja schon ungewöhnlich wäre

Ich habe das MetaPaket habe ich selber runter geschmissen, damit mir nicht der Kernel beim Update automatisch aktualisiert werden.

Ich glaube auch gar nicht, dass es am Kernelpaket liegt, sondern an grub

Das glaube ich auch. Aber warum?

Hier die Ausgabe von lsblk:

Code: Alles auswählen

lsblk -rf
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
sda1
sda2 ext4  41403b16-cfdb-4678-8803-a2837bf76502 1,3T 58% /
sda3 swap  b1771729-31f1-42a7-8132-8f62448886dc   [SWAP]
sdb
sdb1 ext4  55f564ef-a79b-4fc4-9711-4d4f9cd025e0 1,5T 68% /mnt/backup

Ein fsck habe ich schon durch. Da ist alles i.O.
Und ja es ist ein Hardware-RAID-Controller. Bei Anderen Systemen habe ich diese Probleme nicht.

[smutbert]

Wenn ich versuche Grub aus dem Orginal System zu installiern, dann lande ich trotzdem im Grub rescue.

/dev/sdb hängt nicht am RAID-Controller und ist im BIOS auch nicht als Bootdevice ausgewählt oder war auf sdb vielleicht einmal ein (anderer) grub oder etwas in der Richtung?
Um das auszuschließen dass irgendein alter Boocode auf sdb die Probleme verursacht, könntest du den Bootcode von sdb löschen (wenn du mutig genug bist). Mit aller gebotenen Vorsicht also so etwas wie

Code: Alles auswählen

dd if=/dev/zero of=/dev/sdb bs=446 count=1 seek=0

Sonst fällt mir, wenn das RAID in Ordnung ist, auch nichts anderes ein als grub noch einmal aus dem laufenden System heraus zu installieren und dabei auf die Meldungen zu achten (oder die Meldungen zu posten):

Code: Alles auswählen

grub-install --verbose --recheck /dev/sda
update-grub

Wenn da dann steht, dass grub erfolgreich installiert wurde und du von sda bootest, sollte eigentlich nichts schiefgehen können.

[oln]

Die sdb ist eine Backup-Platte. Die war komplett leer.
Dort sind auch keine Fragmente von Grub drauf:

Code: Alles auswählen

[root@saturn boot]#  dd bs=512 count=1 if=/dev/sdb | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
1+0 Datensätze ein
1+0 Datensätze aus
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
512 bytes copied, 0,000118451 s, 4,3 MB/s
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0100 eefe ffff 0100 0000 ffff ffff 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.

Wenn ich das auf sda laufen lasse, dann sieht es so aus, als wenn Grub dort installiert ist:

Code: Alles auswählen

[root@saturn boot]#  dd bs=512 count=1 if=/dev/sda | xxd
00000000: eb63 9000 0000 0000 0000 0000 0000 0000  .c..............
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
1+0 Datensätze ein
1+0 Datensätze aus
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0080 0008 0000  ................
00000060: 0000 0000 fffa 9090 f6c2 8074 05f6 c270  ...........t...p
00000070: 7402 b280 ea79 7c00 0031 c08e d88e d0bc  t....y|..1......
00000080: 0020 fba0 647c 3cff 7402 88c2 52bb 1704  . ..d|<.t...R...
512 bytes copied, 0,000112196 s, 4,6 MB/s
00000090: f607 0374 06be 887d e817 01be 057c b441  ...t...}.....|.A
000000a0: bbaa 55cd 135a 5272 3d81 fb55 aa75 3783  ..U..ZRr=..U.u7.
000000b0: e101 7432 31c0 8944 0440 8844 ff89 4402  ..t21..D.@.D..D.
000000c0: c704 1000 668b 1e5c 7c66 895c 0866 8b1e  ....f..\|f.\.f..
000000d0: 607c 6689 5c0c c744 0600 70b4 42cd 1372  `|f.\..D..p.B..r
000000e0: 05bb 0070 eb76 b408 cd13 730d 5a84 d20f  ...p.v....s.Z...
000000f0: 83d0 00be 937d e982 0066 0fb6 c688 64ff  .....}...f....d.
00000100: 4066 8944 040f b6d1 c1e2 0288 e888 f440  @f.D...........@
00000110: 8944 080f b6c2 c0e8 0266 8904 66a1 607c  .D.......f..f.`|
00000120: 6609 c075 4e66 a15c 7c66 31d2 66f7 3488  f..uNf.\|f1.f.4.
00000130: d131 d266 f774 043b 4408 7d37 fec1 88c5  .1.f.t.;D.}7....
00000140: 30c0 c1e8 0208 c188 d05a 88c6 bb00 708e  0........Z....p.
00000150: c331 dbb8 0102 cd13 721e 8cc3 601e b900  .1......r...`...
00000160: 018e db31 f6bf 0080 8ec6 fcf3 a51f 61ff  ...1..........a.
00000170: 265a 7cbe 8e7d eb03 be9d 7de8 3400 bea2  &Z|..}....}.4...
00000180: 7de8 2e00 cd18 ebfe 4752 5542 2000 4765  }.......GRUB .Ge
00000190: 6f6d 0048 6172 6420 4469 736b 0052 6561  om.Hard Disk.Rea
000001a0: 6400 2045 7272 6f72 0d0a 00bb 0100 b40e  d. Error........
000001b0: cd10 ac3c 0075 f4c3 0000 0000 0000 0000  ...<.u..........
000001c0: 0100 eefe ffff 0100 0000 ffff ffff 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.

Reboot kann ich erst heute Nacht machen.

[oln]

Guten Morgen ins Forum.
Leider war der Reboot nicht erfolgreich. Ich bin wieder in der Grub-Konsole gelandet.
Was habe ich vorher gemacht?

Code: Alles auswählen

grub-install --verbose --recheck /dev/sda
update-grub

Ich habe kein neuen Kernel installiert.
Also muss es an Grub liegen.
Ok dann mal den Grub analysieren:
Als erstes mal den Bootsektor:

Code: Alles auswählen

[root@saturn ~]# file -s -N -F';' /dev/sd*|egrep 'GR|ID=0xee|data$'| tr -s ';' '\n'
/dev/sda1
 data
/dev/sdb
 DOS/MBR boot sector
 partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 4294967295 sectors, extended partition table (last)

Sieht erst einmal ok aus.
Dann MBR ansehen:

Code: Alles auswählen

[root@saturn ~]# hexdump -s0 -n512 -C /dev/sda
00000000  eb 63 90 00 00 00 00 00  00 00 00 00 00 00 00 00  |.c..............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000050  00 00 00 00 00 00 00 00  00 00 00 80 00 08 00 00  |................|
00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|
00000080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 bb 17 04  |. ..d|<.t...R...|
00000090  f6 07 03 74 06 be 88 7d  e8 17 01 be 05 7c b4 41  |...t...}.....|.A|
000000a0  bb aa 55 cd 13 5a 52 72  3d 81 fb 55 aa 75 37 83  |..U..ZRr=..U.u7.|
000000b0  e1 01 74 32 31 c0 89 44  04 40 88 44 ff 89 44 02  |..t21..D.@.D..D.|
000000c0  c7 04 10 00 66 8b 1e 5c  7c 66 89 5c 08 66 8b 1e  |....f..\|f.\.f..|
000000d0  60 7c 66 89 5c 0c c7 44  06 00 70 b4 42 cd 13 72  |`|f.\..D..p.B..r|
000000e0  05 bb 00 70 eb 76 b4 08  cd 13 73 0d 5a 84 d2 0f  |...p.v....s.Z...|
000000f0  83 d0 00 be 93 7d e9 82  00 66 0f b6 c6 88 64 ff  |.....}...f....d.|
00000100  40 66 89 44 04 0f b6 d1  c1 e2 02 88 e8 88 f4 40  |@f.D...........@|
00000110  89 44 08 0f b6 c2 c0 e8  02 66 89 04 66 a1 60 7c  |.D.......f..f.`||
00000120  66 09 c0 75 4e 66 a1 5c  7c 66 31 d2 66 f7 34 88  |f..uNf.\|f1.f.4.|
00000130  d1 31 d2 66 f7 74 04 3b  44 08 7d 37 fe c1 88 c5  |.1.f.t.;D.}7....|
00000140  30 c0 c1 e8 02 08 c1 88  d0 5a 88 c6 bb 00 70 8e  |0........Z....p.|
00000150  c3 31 db b8 01 02 cd 13  72 1e 8c c3 60 1e b9 00  |.1......r...`...|
00000160  01 8e db 31 f6 bf 00 80  8e c6 fc f3 a5 1f 61 ff  |...1..........a.|
00000170  26 5a 7c be 8e 7d eb 03  be 9d 7d e8 34 00 be a2  |&Z|..}....}.4...|
00000180  7d e8 2e 00 cd 18 eb fe  47 52 55 42 20 00 47 65  |}.......GRUB .Ge|
00000190  6f 6d 00 48 61 72 64 20  44 69 73 6b 00 52 65 61  |om.Hard Disk.Rea|
000001a0  64 00 20 45 72 72 6f 72  0d 0a 00 bb 01 00 b4 0e  |d. Error........|
000001b0  cd 10 ac 3c 00 75 f4 c3  00 00 00 00 00 00 00 00  |...<.u..........|
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

Nun noch die Grubversion auslesen:

Code: Alles auswählen

[root@saturn ~]# hexdump -v -s 0x80 -n  2 -e '2/1 "%x" "\n"'  /dev/sda
020 <--steht für GRUB 2 (Version 1.99)
[root@saturn ~]# hexdump -v -s 0x80 -n  2 -e '2/1 "%x" "\n"'  /dev/sda1
31d2 <--steht für  Grub 2 core.img

Es sieht alles ok aus.
Nun weiß ich echt nicht mehr weiter.
Letzter Strohhalm: boot-info-script
Das Result hier: 41237

[jph]

Beim Update auf den o.G. Kernel habe ich massieve Probleme. Ich lande dann immer im Grub rescue Modus.
Dort bekomme ich auch nicht den Kernel zum laufen.

Welche Fehlermeldung spuckt Grub denn aus?

[oln]

Welche Fehlermeldung spuckt Grub denn aus?

Wie ich schon schrieb. Eben Keinen.
Ich lande in der Grub Rescue Konsole nach der Installation. Allerdings habe ich ja herausgefunden, dass es nicht an der Installation des Paketes liegt(siehe vorherige Posts).

[smutbert]

Es sieht ja auch so als würde alles passen. Ist es möglich, dass die Dateien auf /dev/sda2 hinter irgendeiner kritischen Grenze liegen (zumindest irgendeine von grub in »/boot/grub«), auf die grub bzw. das BIOS nicht mehr zugreifen kann (das hatten wir gerade in einem anderen Thread, sonst wäre ich gar nicht auf die Idee gekommen). Ich weiß auch nicht welche Rolle der RAID-Controller dabei spielen könnte, der muss ja auch ein eigenes BIOS haben.

Wenn das die Ursache wäre, würde eine /boot-Partition am Anfang des RAID-Verbundes helfen, aber da ist halt kein Platz. Wie machst du das denn mit dem USB-Stick auf 650 km Entfernung – ich meine du könntest sonst ja auch als provisorische Lösung /boot auf einen USB-Stick legen und davon booten – das würde das Problem vorerst mit an Sicherheit grenzender Wahrscheinlichkeit beheben.


Als weitere mögliche Ursache fällt mir nur noch die wohl etwas weit hergeholte Möglichkeit einer kaputten Datei ein. Mit debsums könntest du die Dateien von grub prüfen, also vor allem

Code: Alles auswählen

debsums grub-pc-bin

[oln]

Moin.

Es sieht ja auch so als würde alles passen. Ist es möglich, dass die Dateien auf /dev/sda2 hinter irgendeiner kritischen Grenze liegen (zumindest irgendeine von grub in »/boot/grub«), auf die grub bzw. das BIOS nicht mehr zugreifen kann

Ja sowas hatte ich auch schon gelesen. Es ist nicht optimal partitioniert. Leider habe ich den Server nicht aufgesetzt. Ich mach immer eine extra Bootpartition.

Wie machst du das denn mit dem USB-Stick auf 650 km Entfernung

Magie! Quatsch. Das Bord hat eine BMC Konsole. Der USB-Stick steckt permanent da drin.

ich meine du könntest sonst ja auch als provisorische Lösung /boot auf einen USB-Stick legen und davon booten – das würde das Problem vorerst mit an Sicherheit grenzender Wahrscheinlichkeit beheben.

Ja das würde gehen. Aber passen tut mir das nicht. Mal sehen wie ich da weiter vor gehe.

Als weitere mögliche Ursache fällt mir nur noch die wohl etwas weit hergeholte Möglichkeit einer kaputten Datei ein. Mit debsums könntest du die Dateien von grub prüfen, also vor allem

Code: Alles auswählen

debsums grub-pc-bin

Hab jetzt mal alles kontrolliert. Keine Fehler.

Danke für die Antworten. Es wird wohl keine Einfache Lösung geben. Aber ich gebe nicht auf.

[oln]

Da ich nicht aufgebe, frage ich mich ob das etwas bringen würde?
Ich glaube da wirklich an eine Bios-Bug.

[smutbert]

Bei der Anleitung dürftest an diesem 1. scheitern

Create a partition of at least 200 MB of free space. This partition can be created from existing unallocated space, or by shrinking another partition and using the newly-created free space.

1. On older systems or very large drives, ensure the boot partition is within the area recognised by the BIOS. Check the BIOS settings for the reported disk size. It may be necessary to place the new boot partition before the Linux/Ubuntu partition in order for the BIOS to see it.

https://help.ubuntu.com/community/CreateBootPartitionAfterInstall

Du hast schlicht keine Partition innerhalb von zB der ersten 32 GB (ist egal selbst wenn die entscheidende Grenze bei 128 GB oder noch höher liegen würde, würde das nichts ändern), mit mindestens 200 MB (wobei das eh nicht allzu großzügig bemessen ist), die du verkleinern und eine passende /boot-Partition anlegen könntest.

Die einzige Partition innerhalb dieser Grenzen ist die BIOS Boot Partition und auf die bist du angewiesen, weil du mit mehr als 2 TB bist nicht an gpt (statt msdos/mbr-Partitionierung) vorbei kommst. (Ist aber eh nur ein Megabyte, das die nicht weiterhilft.)
Die nächsten 3,6 TB sind deine /-Dateisystem, das du zuerst verkleinern und dann als ganzes nach hinten schieben müsstest – selbst wenn das möglich ist, ist es schneller, einfacher und sicherer den Dateisysteminhalt zu kopieren, neu zu partitionieren und hinterher die Daten wieder zurückzuspielen.

Auf sdb sieht es auch nicht besser aus, da gibt es auch nur eine große Partition, die über alle kritischen Grenzen hinaus geht. Im Grunde also dasselbe wie bei sda.
Deshalb habe ich ja überhaupt erst den USB-Stick erwähnt.

[oln]

Moin,
danke smutbert für die Antwort.
Heute morgen ein ernüchterde Nachricht bekommen. Es dröhnt ein Piepen aus dem Serverraum. Ok eine Platte defekt. Der Rebuild läuft noch. Aber das könnte die Probleme erklären, weil es ja vorher funktioniert hat.
Mal sehen ob sich das dann in Luft auflößt.