Hilfe!!! Cant' find ext3 on dev dm-0

M

manilo101

Grünschnabel
Hallo in die Runde
Scheinbar hats mir das ext3-Dateisystem zerschossen. Ich kam vorgestern früh an den Rechner. Er war eingefroren. Warmstart gemacht (umschalten auf Konsole ging nicht mehr) und dann kam die Meldung wie im Bild zu sehen.

http://www.fedoraforum.de/download/file.php?id=81

Mit Knoppix gebootet sehe ich , dass das Dateisystem fehlt bzw. unbekannt ist. Also scheinbar ist die Partition noch da aber das ext3-Dateisystem nicht mehr.

Könnte die Ursache Spannungsschwankung im Netz sein? Annahme dazu gibt mir, dass ich vor etwa 3 Wochen genau das gleiche auf ner Windows-Box hatte. Dort war die MFT zerstört. Konnte das beheben und kam zur Sicherung an das System. Es lief dann wieder um dann 3 Tage später wieder zu hängen. Hab die Platte dann per Garantie getauscht bekommen.

Wie sollte ich jetzt am besten weiter vorgehen? Ich hab ein backup der Platte gemacht in dem Zustand, wie sie jetzt ist. Es könnte also auch die Try-and-Error Methode zum Einsatz kommen.

Ich habe bereits etwas gefunden zur Datenrettung, was gut klang aber leider nicht funzt. Unter http://www.linuxforen.de/forums/showthread.php?t=218757 der 5.Beitrag war eigentlich gut gedacht. Hat aber nix gebracht. Es war danach alles wie vorher.

Ich wäre für konstruktive Hilfe sehr dankbar. Auf dem Rechner liegen die kommpletten Wetterdaten meiner Station seit Februar 2004. Die Datensicherung lag auf dem Windows-Rechner, der vor 3 Wochen geflogen ist. Dumm nur, dass sie dort nicht mehr zu finden ist. Das hab ich aber erst heute gemerkt als ich nach ihr suchte.

Danke
MfG
Manilo
 
Ich behaupte mal, das nur der MBR zerschossen ist.

Schon mal mit testdisk oder auch super grub disc versucht den wieder herzustellen?
 
Wär der MBR kaputt würde der das Linux doch gar nicht laden...

Beschreib doch bitte erstmal wie deine Platte aufgebaut war, bevor wir hier mutmaßen müssen. Hast du cryptsetup benutzt root auf LVM gehabt, ... ?? Vorher können wir hier auch nur raten. Als nächstes bietet es sich an mal zu versuchen mit e2fsck zu prüfen ob man den ext3 superblock an einer der anderen Stellen wiederfindet, der wird beim Erstellen in gleichmäßigen Abständen gespeichert und zwar gerade für diesen Fall.

e2fsck -b 8192 (hoffe es ist bei dir vielfaches von 8192 oder alternativ das was dir bei der Erstellung angezeigt wurde und du sicher notiert hast *g*) kann da helfen, setzt aber voraus, dass dein ursprüngliches root-device noch da ist..
 
Der MBR enthält zwei Teile:
Den Bootcode (1-446) + die Partitionstabelle (4 x 16 =64 Byte) + Kennung 2 Byte.

Was all diese Tools machen, ist das Suchen nach führenden Sektoren, die eine Kennung enthalten.

Möglicherweise ist die Partitionstabelle kaputt.
Aber das ist spekulativ.

Ein Versuch ist es aber Wert, sei es auch nur diesen Fehler auszuschließen.

Wolfgang
 
Danke erst mal für eure Hilfe. Das Fedora wurde normal installiert auf der einen Platte, die jetzt den Fehler hat. Die Partitionierung erfolgte automatisch dem autom. Vorschlag bei der Installation. Ca. 200MB /boot auf hda1 und der Rest komplett hda2 als / . Während ich das schreibe fällt mir auf, dass ja auch gar keine swap mehr da ist...
Die 2 Platte im LVM kam später hinzu und wurde als /daten gemountet. Das alles ohne mein Zutun sondern durch die Fedora Routinen. Ich hab nur den MP gewählt. Die /daten scheint ok zu sein.
e2fsck hab ich schon gemacht. Bei allen Superblocks und den Sicherungen kommt die Meldung "Bad magic number".

Welche Infos braucht ihr noch?

Danke
MfG
Manilo
 
Super, schon mal ein Anfang. Ein fdisk -l /dev/hda wäre super mit dem Kommentar was du erwartet hast. Wenn die Partitionstabelle beschädigt ist, und danach sieht es aus wenn Partitionen wie z. B. swap verschwunden sind wäre
a) eine Sicherung der Partitiontstabelle super gewesen und
b) die Vorschläge meiner Vorredner angebracht, mit den Tools musste ich glücklicherweise noch nicht arbeiten..

Wolfgang: Ich weiss, was im MBR zu finden ist, aber ich würde es für unwahrscheinlich halten, dass gerade nur die Tabelle hopps gegangen ist und der Bootloader blieb. Trotzdem hast du Recht, meinen ersten Satz könnte man streichen. Wüsste ich den Tag dafür hätte ichs sogar getan :-)
 
Zuletzt bearbeitet:
SO, hier die Ausgabe:

root@Knoppix:/ramdisk/home/knoppix# fdisk -l /dev/hda

Platte /dev/hda: 80.0 GByte, 80026361856 Byte
255 Köpfe, 63 Sektoren/Spuren, 9729 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes

Gerät boot. Anfang Ende Blöcke Id System
/dev/hda1 * 1 25 200781 83 Linux
/dev/hda2 26 9729 77947380 8e Linux LVM


Was hatte ich erwartet? *rotwerd* ich muss sagen, ich hab mir beim Partionieren keine Gedanken gemacht und hab das automatich von anaconda erledigen lassen. Der Rechner soll nur ein wenig routen und über eine virtuelle Box mit WinXP meine Wetterdaten verwalten. Ich hab keinen Wert auf die Partionierung gelegt. Ich weiß nicht, wie Fedora die Platte aufteilt.

Danke
MfG
Manilo
 
Hmm, für die Zukunft: Partitionierung (fdisk -l auf allen Platten) sichern!
Für jetzt kann ich auch nur supersucker zitieren...
Ich behaupte mal, das nur der MBR zerschossen ist.

Schon mal mit testdisk oder auch super grub disc versucht den wieder herzustellen?

Wenn das e2fsck -b 8192 /dev/hda1 nichts gebracht hat, kanns sein, dass die Partitiontstabelle kaputt ist. Aber es ist schon seeehrr seltsam, dass die nicht kaputtgeht sondern sich nur verändert... Was hast du denn zuletzt gemacht/geändert/installiert?

Moment: Hast du Festplattenverschlüsselung oder so etwas angeschaltet? Ich frage weil er ja versucht dm-0 als Root device zu mounten...???
 
255Ich habe gar nix gemacht. Der Rechner lief schon bestimmt eine Woche. Als Prog lief VirtualBox. Darin ein Windows XP. In dem XP die Wettersoftware WsWin. Diese liest alle 3 Minuten einen Datenlogger aus. Der ist seriell an den PC gestöpselt. Alle 15 Minuten werden Daten via WS_FTP ins Internet gestellt. Evtl. war noch ein Firefox gestartet weil ich hin und wieder auch mal im Netz surfe um mir die Wetterdaten zu besorgen. Installiert wurde schon länger nix mehr.
Über das dm-0 hab ich mich auch gewundert. Hab über google gelesen, dass das was mit verschlüsselten Partionen zu tun haben muss. Aber ich habe keine Verschlüsselung verwendet. Könnte ein Hackerangriff schuld sein? Angemeldet war ich als normaler Benutzer. Aber VirtualBox lief mit root-Rechten da sonst der Zugriff auf die serielle Schnittstelle nicht funktioniert.
Ich kan mir nicht vorstellen, dass super grub disc was ausrichten kann. Das Grub-Boot-Menü kommt ordentlich. Dann kann ich auch den Kernel auswählen (der vorhergehnde ist nach einem update noch da - wenn ich den nehme kommt die gleiche Meldung).
TestDisk hab ich in der 6.6 Version. Aber ich komm nicht ganz klar damit und dem LVM. Wenn ich TD mit search tiefer suchen lasse findet er folgendes: (muss ich von Hand vom Foto abtippen weil ich unter knoppix meine Digicam nicht gemountet bekomme):

Disk 80 - 80GB / 74 GiB - CHS 9729 255 63
Partiton Start End Size in sectors
D Linux_____________0___1______24__254__63________401562 [/boot]
D Linux LVM_____13_0___1___9728__254__63_____156087540
D Linux LVM____25__0___1___9728__254__63_____155894760
D Linux ________33__0___1___9476__254__63_____151717860
D Linux _____3600___1___1__ 4629__254__63______16546887 [/daten]

vor allem die letzte Zeile stimmt mich recht hoffnungsvoll das da noch was geht. Ich weiß aber nicht wie ich es anstellen soll. Ich hab mit TD schon mal ne NTFS wieder hergestellt. Der Eintrag muss doch grün werden und dann mit write übernommen werden. Aber das ist schon ne Weile her.

Danke
MfG
Manilo
 
Wo liegen denn die Daten? Um die geht es doch letztendlich oder? Was passiert wenn du mit einer CD bootest und dann das LVM Volume versuchst zu mounten?
( vgscan, vgchange -ay <vgname> , lvdisplay, mount /dev/<vgname>/<lvname> /mnt, ls /mnt)

EDIT: Hast du Jabber?
 
Ich glaub ich muss erst mal sagen, dass ich reiner Linux-Anwender bin. Ich kann mein System meinen Zwecken entsprechend konfigurieren aber sonst hab ich kein Linux-Spezial-Wissen. LVM mounten? Ist für mich ein Fremdwort. Ich denke, dass ich das Image der Virtuellen Box unter /daten angelegt hab. Wenn ich das wieder bekommen könnte wäre alles paletti. Der Rest ist Kleinkram den ich neu beschaffen kann.
Kannst du mir das mit dem LVM mounten genauer erklären?

Danke
MfG
Manilo

Edit:

root@Knoppix:/ramdisk/home/knoppix# vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2

wie weiter?

Danke
 
Zuletzt bearbeitet:
Kurzer LVM Crashkurs: (sei froh, dass ich gerade nicht in RTFM Stimmung bin :-) )
LVM ermöglicht es den Plattenplatz dynamisch aufzuteilen, ähnlich wie Partitionen nur nicht in der Anzahl beschränkt. Außerdem lassen sich neue Partitionen jederzeit erstellen und vorhandene verkleinern/vergrößern. Zusammengefasst: extrem coole Sache.

Jetzt zum Aufbau von LVM. LVM kennt auf unterster Ebene die PhysicalVolumes (PV), das sind die Partitionen auf den Platten, die für LVM verwendet werden. Das kann eine einzige sein, oder aber auch mehrere Partitionen auf verschiedenen Platten. Diese PVs werden in VolumeGroups zusammengefasst. Eine VolumeGroup (VG) ist ein Konglomerat von einer oder mehreren PVs. Dies dient mehr oder weniger zur Strukturierung.

Innerhalb einer VG kann man LogicalVolumes anlegen (LV) Diese LVs fassen Teile der VG in eine Art virtuelle Partition zusammen. Mit LVs kannst du arbeiten wie mit Partitionen, verschlüsseln, formatieren, ... alles kein Problem. Ein LV gehört immer in eine VG un bedient sich aus den PVs die zu der VG gehören. Man kann jederzeit neue PVs in die VG einhängen und die LVs kann man jederzeit vergrößern/verkleinern (man muß nur dasselbe nachher/vorher mit dem Dateisystem darauf machen).

So, was du jetzt mit vgscan gemacht hast: Dein Rechner hat alle Partitionen der Platten nach PVs durchsucht und daraus die VolumeGroups zu denen diese gehören ausgelesen. Nun wurden die VGs initialisiert/geöffnet.

Näcshter Schritt: Damit du mit den LVs arbeiten kannst, müssen diese aktiviert werden. Damit du das nicht mit jedem einzeln machst, gibt es den Befehl
vgchange -ay VolGroup00
der alle LVs in der VG "VolGroup00" aktiviert. Bitte einmal ausführen.

Der Befehl vgdisplay listet dann alle bekannten VGs auf, der Befehl lvdisplay alle bekannten LVs aller VGs. Bitte beides einmal ausführen. Theoretisch sollte bereits im /dev Verzeichnis ein Eintrag der Art /dev/<VG-Name> also in deinem Fall /dev/VolGroup00 erstellt worden sein (ein Verzeichnis) Bitte prüfen.

Nach dem vgchange -ay .... sollten in dem Verzeichnis ausserdem Einträge mit den Namen der LVs angelegt worden sein (siehe lvdisplay) mit ls /dev/<VG-Name> prüfen. Diese LVs solltest du theoretisch mounten können.
 
Sieht gut aus.
root@Knoppix:/ramdisk/home/knoppix# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 74,31 GB
PE Size 32,00 MB
Total PE 2378
Alloc PE / Size 2377 / 74,28 GB
Free PE / Size 1 / 32,00 MB
VG UUID BcKFhU-1mtO-qmqu-nJwo-G74O-PiIx-ngt5Py

root@Knoppix:/ramdisk/home/knoppix# lvdisplay
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID tTtNHo-kdT8-OtN2-T0EJ-Vgcx-z15o-3T3P84
LV Write Access read/write
LV Status available
# open 0
LV Size 72,34 GB
Current LE 2315
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:0

--- Logical volume ---
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV UUID e9fN8g-nE2v-6j76-SXS6-dlLm-auGl-kRCBno
LV Write Access read/write
LV Status available
# open 0
LV Size 1,94 GB
Current LE 62
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:1
.
.
.
root@Knoppix:/dev# cd VolGroup00/
root@Knoppix:/dev/VolGroup00# ls
LogVol00 LogVol01
root@Knoppix:/dev/VolGroup00#

Ich lass da jetzt trotzdem erst mal so sein. Ich mach das morgen nach der Arbeit. Ich bin total alle und muss in die Falle. Ich bin ein wenig unkonzentriert. Es geht um vier wieder los und ich muss um drei aufstehen. Und wenn ich mich unbemerkt vertippe ist evtl alles im Eimer.

Ich meld mich wieder.
Ich dank dir wie verrückt.

MfG
GN8
Manilo
 
Meiner Meinung nach ist da an der Platte nichts kaputt, aber die Partitionen werden nicht durch den LVM gefunden, vmtl. weil dessen Konfiguration nicht richtig ist oder geaendert wurde. Und der Rechner bootet nicht, weil er beim Uebergang des Wurzelverzeichnisses von den initrd auf die Partition die Partition nicht findet. Dabei kommt oft erschwerend hinzu, dass die Partition nicht durch root=/dev/hda1 o.ae. sondern durch ein label angegeben ist. Oben auf dem screen-Foto steht dass es ein ext2fs ist, unten wo die Uebergabe initrd->Part. nicht klappt, steht dagegen es wurde als ext3 angegeben.

Bitte poste mal /etc/lilo.conf (oder /grub/menu.lst), /etc/fstab , /etc/lvm.conf
 
Zuletzt bearbeitet:
Joa, ist ne wichtige Sache aufzuhören, wenn man so hibbelig und nervös wird, habe mir damals bei solcherart Rettungsversuchen von drei RAIDs zwei zerschossen (System und usr glaube ich) bis dann beim dritten alles glatt lief (waren die Daten, puh) Also lieber einmal durchschlafen. Viel kaputtmachen kannst du aber mit diesen Kommandos glücklicherweise nicht. Wenn du beide dann mal gemountet hast und deine daten evtl. gefunden hast dann würde ich die erstmal wegsichern.
Dann würde ich tun was werner1234 vorschlägt und die Dateien posten, da kann ich aber auch aus Unkenntnis deiner Distribution und Setups nicht weiterhelfen..
 
So, ich hoffe ihr habt den ersten Mai gut überstanden ;-)

Mounten will nicht: Auf LogVol00:

mount /dev/VolGroup00/LogVol00 /mnt/vol" gibt folgendes:

"mount: you must specify the filesystem type"

also

mount -t ext3 /dev/VolGroup00/LogVol00 /mnt/vol

mount: wrong fs type, bad option, bad superblock on /dev/mapper/VolGroup00-LogVol00,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

dmesg:
VFS: Can't find ext3 filesystem on dev dm-0.

LogVol01:

mount /dev/VolGroup00/LogVol01 /mnt/vol/

/dev/VolGroup00/LogVol01 looks like swapspace - not mounted
mount: you must specify the filesystem type

mount -t ext3 /dev/VolGroup00/LogVol01 /mnt/vol/
mount: wrong fs type, bad option, bad superblock on /dev/VolGroup00/LogVol01,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

dmesg:
VFS: Can't find ext3 filesystem on dev dm-1


So und dann
Bitte poste mal /etc/lilo.conf (oder /grub/menu.lst), /etc/fstab , /etc/lvm.conf

/etc/fstab , /etc/lvm.conf geht leider nicht - komm ja nicht ran. Ansonnsten:

root@Knoppix:/media/hda1/grub# cat menu.lst
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.24.3-34.fc8 )
root (hd0,0)
kernel /vmlinuz-2.6.24.3-34.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb qu iet
initrd /initrd-2.6.24.3-34.fc8.img
title Fedora (2.6.24.3-12.fc8 )
root (hd0,0)
kernel /vmlinuz-2.6.24.3-12.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb qu iet
initrd /initrd-2.6.24.3-12.fc8.img

Dateisystem scheint futsch zu sein. So ein Mist.

MfG
Manilo
 
Zuletzt bearbeitet:
Uebel. War die Partition denn formatiert ? Wenn dann ist sie wohl wirklich futsch Starte mal mit einem kleinen live-CD zBsp SLAX und mache dann fdisk -l und ueberhaupt guck dir mal dmesg an was da fuer Geraete und Partitionen gemeldet werden. Poste die Resultate mal
 
Zuletzt bearbeitet:
So, ich bin auch wieder da. Sorry aber beruflicher Stress ... Danke für die Geduld.

Die entsprechenden Ausgaben von dmesg:

Probing IDE interface ide0...
hda: WDC WD800JB-00JJC0, ATA DISK drive
hdb: ST340015A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: _NEC DVD_RW ND-3550A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=65535/16/63
hda: cache flushes supported
hda: hda1 hda2
hdb: max request size: 128KiB
hdb: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63
hdb: cache flushes supported
hdb: hdb1

Stimmt soweit ich das sehe. Die Angaben zum Dateisystem kann ich nicht deuten außer, das er nix findet:

Warning: /proc/ide/hd?/settings interface is obsolete, and will be removed soon!
Unable to identify CD-ROM format.
VFS: Can't find an ext2 filesystem on dev hda.
ReiserFS: hda: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on h
da
FAT: invalid media value (0x00)
VFS: Can't find a valid FAT filesystem on dev hda.
Unable to identify CD-ROM format.
VFS: Can't find an ext2 filesystem on dev hdb.
ReiserFS: hdb: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on h
db
FAT: invalid media value (0xb9)
VFS: Can't find a valid FAT filesystem on dev hdb.

Die Ausgabe von fdisk sieht folgendermaßen aus:

root@Knoppix:/ramdisk/home/knoppix# fdisk -l

Platte /dev/hda: 80.0 GByte, 80026361856 Byte
255 Köpfe, 63 Sektoren/Spuren, 9729 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes

Gerät boot. Anfang Ende Blöcke Id System
/dev/hda1 * 1 25 200781 83 Linux
/dev/hda2 26 9729 77947380 8e Linux LVM

Platte /dev/hdb: 40.0 GByte, 40020664320 Byte
255 Köpfe, 63 Sektoren/Spuren, 4865 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes

Gerät boot. Anfang Ende Blöcke Id System
/dev/hdb1 1 4865 39078049+ 83 Linux

Gibst es noch Hoffnung auf Datenrettung?

Danke
MfG
Manilo
 
Also meine Meinung:

Etwas komisch sind die unkorrekten BIOS-Id's die normalerweise mit 0x80 anfangen sollten, das koennte eine BIOS-Fehlfunktion sein. Linux schafft es aber idR die Geraete selbst zuzuweisen.

Die Partitionen sind vorhanden. Die erste Partition der ersten Platte /dev/hda1 ist aber sehr klein, also wohl kaum eine brauchbare Partition mit normalen Daten. fdisk findet die Partitionen zumindest.

Beim mounten wird versucht, /dev/hda und /dev/hdb zu mounten, das ist natuerlich erfolglos, es muessen /dev/hda1 , /dev/hda2 und /dev/hdb1 gemountet werden. Moeglicherweise werden sie mit CDs verwechselt, eben weil die og. BIOS-Werte falsch sind.

Versuche nun mal, mit einem SLAX-live CD o.ae. diese Partitionen explizit zu mounten, falls sie (bei SLAX ueblich) nicht automatisch gemounten werden (... nach /mnt/hda1 , /mnt/hda2 , /mnt/hdb1). Also tippe ein: mkdir /hda1 , dann mount /dev/hda1 /hda1 . Und poste was dann passiert. Wenn es nicht geht, mache ferner ls -l /dev/hda1 usw und poste auch davon das Resultat. Falls die Partitionen irgendwie formatiert sind, muesste das eigentlich gehen. Aber vielleicht hast du Pech gehabt und beim automatischen Partitionieren bei Mdrk oder RedHat Formatieren nicht disabelt sodass die frueher da vhd Daten ueberformatiert wurden.
 
Die erste Partition ist ne reine boot-Partition. Deswegen so klein. Ansonnsten hier
mounten sieht folgendermaßen aus:

root@Knoppix:/ramdisk/home/knoppix# mount /dev/hda2 /media/hda2
mount: you must specify the filesystem type

Dann mit Typ:

root@Knoppix:/ramdisk/home/knoppix# mount -t ext3 /dev/hda2 /media/hda2
mount: wrong fs type, bad option, bad superblock on /dev/hda2,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

dmesg meint: VFS: Can't find ext3 filesystem on dev hda2.

und ls:

root@Knoppix:/ramdisk/home/knoppix# ls -l /dev/hda2
brw-rw---- 1 root disk 3, 2 2008-05-09 18:34 /dev/hda2

Danke
MfG
Manilo
 

Ähnliche Themen

Heimserver Konfiguration für Ubuntu Server?!

Dateisystem defekt, kein Start von Openfiler möglich. Error 22. Bitte um Hilfe

Laptop wird unter SuSe super heiß und stürzt regelm. ab

Filesystem von Truecrypt-Container beschädigt !?

Fileserver LVM post mortem

Zurück
Oben