Hallo liebes Ubuntu-Forum, leider tappe ich hier absolut im Dunklen und komme mit meinem Problem nicht weiter. Da dies mein erster Eintrag ist, hoffe ich dass ihr Nachsehen habt, wenn ich nicht gleich alles richtig notiere. Ich gebe mir Mühe!!!

Ich habe ein Distributions-Upgrade von 9.04 auf 9.10 gemacht ... und jetzt geht nur noch sehr sehr wenig. Hier die Fakten: Ich habe zwei Festplatten, die zu einem RAID 1 verbunden sind: sda und sdb. Zusammen ergeben Sie md0. Hier die Ausgabe von fdisk (in einem funktionierenden Status, wenn ich mit einem alten Kernel hochfahre)

~$ sudo fdisk -l

Platte /dev/sda: 250.0 GByte, 250000000000 Byte
255 Köpfe, 63 Sektoren/Spuren, 30394 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x98deb064

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *       30152       30394     1951897+  82  Linux Swap / Solaris
/dev/sda2               1       30151   242187876   fd  Linux raid autodetect

Partitionstabelleneinträge sind nicht in Platten-Reihenfolge

Platte /dev/sdb: 250.0 GByte, 250000000000 Byte
255 Köpfe, 63 Sektoren/Spuren, 30394 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x000146da

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdb1           30152       30394     1951897+  82  Linux Swap / Solaris
/dev/sdb2               1       30151   242187876   fd  Linux raid autodetect

Partitionstabelleneinträge sind nicht in Platten-Reihenfolge
Platte /dev/md0: 248.0 GByte, 248000282624 Byte
2 Köpfe, 4 Sektoren/Spuren, 60546944 Zylinder
Einheiten = Zylinder von 8 × 512 = 4096 Bytes
Disk identifier: 0x00000000

Festplatte /dev/md0 enthält keine gültige Partitionstabelle

Kleine Zwischenfrage: Muss ich mir Sorgen machen, dass /dev/md0 keine gültige Partitionstabelle enthält?

Wenn ich den Rechner hochfahre, dann bekomme ich als Ausgabe das hier (weiß auf schwarzem Bildschirm, hier habe ich es abgetippt): Das ist das Ergebnis, wenn ich mit dem "neuesten" Kernel (2.6.31-17-generic) hochfahre.

Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
   - check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
Alert! /dev/md0 does not exist. Dropping to a shell!

(initramfs) _

Hier ist die Einträge in menu.lst

lydia@marge:/etc$ cat /boot/grub/menu.lst
# menu.lst - See: grub(8), info grub, update-grub(8)
#            grub-install(8), grub-floppy(8),
#            grub-md5-crypt, /usr/share/doc/grub
#            and /usr/share/doc/grub-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not use 'savedefault' or your
# array will desync and will not let you boot your system.
default		0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout		3

## hiddenmenu
# Hides the menu by default (press ESC to see the menu)
hiddenmenu

# Pretty colours
#color cyan/blue white/blue

## password ['--md5'] passwd
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line)  and entries protected by the
# command 'lock'
# e.g. password topsecret
#      password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret

#
# examples
#
# title		Windows 95/98/NT/2000
# root		(hd0,0)
# makeactive
# chainloader	+1
#
# title		Linux
# root		(hd0,1)
# kernel	/vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##      kopt_2_6_8=root=/dev/hdc1 ro
##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=/dev/md0 ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,1)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
##      alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
##      lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=quiet splash

## should update-grub lock old automagic boot options
## e.g. lockold=false
##      lockold=true
# lockold=false

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(recovery) single
# altoptions=(recovery mode) single

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
##      howmany=7
# howmany=all

## specify if running in Xen domU or have grub detect automatically
## update-grub will ignore non-xen kernels when running in domU and vice versa
## e.g. indomU=detect
##      indomU=true
##      indomU=false
# indomU=detect

## should update-grub create memtest86 boot option
## e.g. memtest86=true
##      memtest86=false
# memtest86=true

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=false

## should update-grub add savedefault to the default options
## can be true or false
# savedefault=false

## ## End Default Options ##

title		Ubuntu 9.10, kernel 2.6.31-17-generic
root		(hd0,1)
kernel		/boot/vmlinuz-2.6.31-17-generic root=/dev/md0 ro quiet splash 
initrd		/boot/initrd.img-2.6.31-17-generic
quiet

title		Ubuntu 9.10, kernel 2.6.31-17-generic (recovery mode)
root		(hd0,1)
kernel		/boot/vmlinuz-2.6.31-17-generic root=/dev/md0 ro  single
initrd		/boot/initrd.img-2.6.31-17-generic

title		Ubuntu 9.10, kernel 2.6.28-17-generic
root		(hd0,1)
kernel		/boot/vmlinuz-2.6.28-17-generic root=/dev/md0 ro quiet splash 
initrd		/boot/initrd.img-2.6.28-17-generic
quiet

title		Ubuntu 9.10, kernel 2.6.28-17-generic (recovery mode)
root		(hd0,1)
kernel		/boot/vmlinuz-2.6.28-17-generic root=/dev/md0 ro  single
initrd		/boot/initrd.img-2.6.28-17-generic

title		Ubuntu 9.10, kernel 2.6.27-16-generic
root		(hd0,1)
kernel		/boot/vmlinuz-2.6.27-16-generic root=/dev/md0 ro quiet splash 
initrd		/boot/initrd.img-2.6.27-16-generic
quiet

title		Ubuntu 9.10, kernel 2.6.27-16-generic (recovery mode)
root		(hd0,1)
kernel		/boot/vmlinuz-2.6.27-16-generic root=/dev/md0 ro  single
initrd		/boot/initrd.img-2.6.27-16-generic

title		Ubuntu 9.10, kernel 2.6.24-26-generic
root		(hd0,1)
kernel		/boot/vmlinuz-2.6.24-26-generic root=/dev/md0 ro quiet splash 
initrd		/boot/initrd.img-2.6.24-26-generic
quiet

title		Ubuntu 9.10, kernel 2.6.24-26-generic (recovery mode)
root		(hd0,1)
kernel		/boot/vmlinuz-2.6.24-26-generic root=/dev/md0 ro  single
initrd		/boot/initrd.img-2.6.24-26-generic

title		Ubuntu 9.10, memtest86+
root		(hd0,1)
kernel		/boot/memtest86+.bin
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

Abschließend noch ein paar Ausgaben, hier könnten die UUID interessant sein (diese Ausgaben sind nach dem Start mit dem zweiten Kernel, kernel 2.6.28-17-generic, erzeugt)

:~$ cat /etc/fstab 
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/md0
UUID=ddd23006-7c41-4f4d-8094-df3949110eda /               ext3    relatime,errors=remount-ro 0       1
# /dev/sda1
UUID=9815454e-f6ea-4b85-8035-3a755a9df322 none            swap    sw              0       0
# /dev/sdb1
UUID=c77f3d5b-2871-40fa-8046-11c66a97d3f1 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0

~$ sudo blkid
/dev/sda1: UUID="9815454e-f6ea-4b85-8035-3a755a9df322" TYPE="swap" 
/dev/sda2: UUID="22fd0cfb-d1ab-9a1f-944d-545da15d1894" TYPE="linux_raid_member" 
/dev/sdb1: UUID="c77f3d5b-2871-40fa-8046-11c66a97d3f1" TYPE="swap" 
/dev/sdb2: UUID="22fd0cfb-d1ab-9a1f-944d-545da15d1894" TYPE="linux_raid_member" 
/dev/md0: UUID="ddd23006-7c41-4f4d-8094-df3949110eda" TYPE="ext3" 

mdadm --detail /dev/md0 
[sudo] password for lydia: 
/dev/md0:
        Version : 00.90
  Creation Time : Wed Oct 22 13:28:50 2008
     Raid Level : raid1
     Array Size : 242187776 (230.97 GiB 248.00 GB)
  Used Dev Size : 242187776 (230.97 GiB 248.00 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Jan 26 19:57:40 2010
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 22fd0cfb:d1ab9a1f:944d545d:a15d1894
         Events : 0.17

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2

sudo mdadm --detail --scan
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=00.90 UUID=22fd0cfb:d1ab9a1f:944d545d:a15d1894

Das schreibe ich, weil nach dem Start mit dem "ersten" Kernel (nachdem er in den initramfs-Modus gegangen ist), folgende Ausgabe kommt (wiederum abgetippt)

cat /etc/mdadm/mdadm.conf
...
# definitions of existing MD arrays
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=22fd0cfb:d1ab9a1f:944d545d:a15d1894

Ist es normal, dass bei fstab eine andere UUID steht?

So, was die ganze Sache betrifft, bin ich etwas ratlos. Im Folgenden habe ich meine Fragen und Problemlösungsansätze zusammen gefasst:

• Es könnte mit dem GRUB zusammenhängen. Wenn ich in dem "alten" Kernel Ubuntu starte, kann ich über Synaptic sehen, dass GRUB 2 nicht installiert ist und hier ist ja auch noch die menu.lst vorhanden. Ich lese aber überall, dass 9.10 nur noch mit GRUB 2 installiert wird... liegt das an dem alten "Kernel"?

• In diesem Zusammenhang habe ich auch gelesen, dass GRUB 2 Probleme hat, Raid 1 Systeme zu erkennen. Muss ich also meine beiden Platten komplett neu anlegen, um 9.10 mit GRUB 2 zum Laufen zu bringen?

Es scheint auf diesen Bug hinzuweisen... allerdings bin ich mir nicht so sicher, welche Aktion ich nun machen soll... https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/427048

Gerne tippe ich noch mehr ab oder schicke noch mehr Details... ich bin jetzt schon unendlich dankbar, wenn sie jemand die Mühe macht, dass hier anzuschauen! Alle Ideen probiere ich gerne aus (die Daten sind schon gerettet)!

sugga

Hallo sugga,

Willkommen hier im Forum. Du hast dir erkennbar sehr viel Mühe mit deinem Beitrag gegeben, und ich werde versuchen, einen Teil deiner Fragen zu beantworten, in der Hoffnung, dass dich das weiter bringt.

Muss ich mir Sorgen machen, dass /dev/md0 keine gültige Partitionstabelle enthält?

Nein, das ist normal.

Ist es normal, dass bei fstab eine andere UUID steht?

Ist bei mir auch so, also normal.

Wenn ich in dem "alten" Kernel Ubuntu starte, kann ich über Synaptic sehen, dass GRUB 2 nicht installiert ist

Dann brauchst du dir über eventuelle Probleme von Grub2 und RAID keine Gedanken zu machen. Mit dem alten Grub geht es auf jeden Fall, ich habe hier eine mit deiner vergleichbare Konfiguration am Laufen: Altes GRUB, booten von einem RAID1, als Jaunty installiert und später auf Karmic aktualisiert. Bei mir läuft auch der 17er Kernel. An der Kombination Grub-Legacy + RAID1 + Karmic sollte es also nicht liegen.

Was ich versuchen würde:

In der BusyBox (das ist die Befehlszeile, in die das System beim missglückten Start springt) das RAID manuell starten:

mdadm --assemble --scan 

oder

mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2

Wenn das geht, solltest du mit Strg-D weiter booten können.

Falls es nicht geht, wäre die Ausgabe von

cat /proc/mdstat 

in der BusyBox interessant.

Falls das Booten nach dem manuellen Zusammensetzen des RAID geht, ist es vermutlich nur nicht richtig in die initramfs eingetragen. Zur Abhilfe (bei laufendem System in einem Terminal):

sudo dpkg-reconfigure mdadm

Wenn weiterhin nichts läuft, es aber mit dem alten Kernel einwandfrei geht, würde ich erstmal den benutzen. Vielleicht ist es nur ein Bug, und nach dem nächsten Update ist alles OK.

Hallo ArnoW und Danke für die Antwort,

ich habe deine Hinweise befolgt - leider ohne Erfolg.

Habe mit dem "neuen" Kernel (Ubuntu 9.10, kernel 2.6.31-17-generic) gestartet, bin nur zu der "Eingabeaufforderung" (initramfs) vorgedrungen.

Die Ausgabe von mdadm --assemble --scan:

mdadm: CREATE user root not found
mdadm: CREATE group disk not found
mdadm: no devices found for /dev/md0

Die Ausgabe von mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2

mdadm: CREATE user root not found
mdadm: CREATE group disk not found
mdadm: cannot open device /dev/sda2: No such file or directory
mdadm: /dev/sda2 has no superblock - assembly aborted

Die Ausgabe von cat /proc/mdstat in der BusyBox

Personalities: [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>

Da das jetzt erstmal nicht ging, benutze ich weiter den "alten" Kernel... leider geht hier der Sound nicht (was, wie ich in einem anderen Thread gelesen habe, mit dem neuen Kernel kein Problem sein sollte). Wenn ich jetzt abschließend noch eine Verständnisfragen stellen darf: wie updated sich denn der neue Kernel, wenn ich nun immer den alten benutze? Und: könnte es an einer Einstellung von dmraid liegen? Auf diese Fährte bin ich hier im Forum auch gestoßen...

(initramfs) dmraid -ay

liefert folgendes Ergebnis

RAID set "invidia_abdbeadj" already active
RAID set "invidia_abdbeadj1" already active
RAID set "invidia_abdbeadj2" already active

Ich hab' das alles abgeschrieben, damit keine Mitverständisse aufkommen, hänge ich noch den Screenshot als Datei an!

Merci vielmals! Sugga

Hallo sugga,

scheint bei dir ein etwas schwierigerer Fall zu sein...

Die Ausgabe von dmraid zeigt in der Tat, dass deine Probleme daher rühren können. Dmraid schnappt sich deine Platten und hängt sie über den Device-Mapper ein, deshalb gelten die "normalen" Festplattenbezeichnungen (z.B. /dev/sda2 nicht mehr). Offenbar hast du (oder hattest vorher einmal) deine Platten an einem nVIDIA-Controller hängen, der im RAID-Modus läuft. Das kann man normalerweise im BIOS einstellen, eine Änderung bringt jetzt aber erst einmal nichts, drum würde ich es lassen.

Gib bitte mal folgende Befehle in der BusyBox ein, und poste die Ausgaben (ein Bildschirmfoto mit der Digicam reicht auch):

dmraid -r

dmraid -s

blkid

Anmerkung: In der BusyBox braucht man normalerweise kein "sudo" voranzustellen, um einen Befehl mit höheren Rechten auszuführen, falls du den Eindruck hast (oder eine entsprechende Ausgabe bekommst), dass du zu wenig Rechte hast, probiers ruhig auch nochmal mit sudo. Falls die Ausgabe von dmraid -s nicht auf den Bildschirm passt, mach dir keine zu große Mühe um ein Foto zu machen, die Ausgabe von dmraid -r allein hilft auch fürs erste. Bei blkid würde ich eine Anzeige erwarten, die sich von der in deinem ersten Post durch andere Namen für die Festplatten unterscheidet.

Probeweise kannst du auch mal das Paket dmraid deinstallieren ("apt-get remove dmraid" eventuell mit sudo davor. Mach das aber nur, wenn du ganz sicher keine RAIDs damit erstellt hast und betreiben willst). Wenn es weg ist, sollten zumindest deine Festplatten wieder unter den gewohnten Namen erreichbar sein und die Befehle zum manuellen Zusammenfügen deines MD-RAIDs aus meinem vorigen Post funktionieren. (Aber: Das automatische mounten beim Systemstart hätte auch mit den durch dmraid veränderten Namen gehen müssen, weil die dabei gar nicht ausgewertet werden, sondern nur die Superblocks auf den Platten).

Salut ArnoW,

ich habe die Eingaben gemacht und ein (!) Bildschirmfoto hat ausgereicht um die Ausgaben zu dokumentieren! Kannst du damit etwas anfangen? Die UUID in der Ausgabe von blkid scheint ja mit der aus meinem ersten Post übereinzustimmen (md0), irgendwie kriegt er wohl nicht die Trennung von sda und sdb in ein Festplattenraid und eine Swap-Partition hin. Vermute ich.

Die Deinstallation von dmraid traue ich mich noch nicht, da die Installation mit dem zweiten Kernel ganz gut läuft und ich den Rechner grade für wichtige Arbeiten brauche und nichts riskieren will. Aufgeschoben ist nicht aufgehoben.

Grüße, S.

Hallo sugga,

die Ausgaben sind eindeutig, aber trotzdem verwirrend. Es wird ein (Fake-)RAID0 erkannt, was erklärt, warum du dein MD-RAID1 nicht zusammenbauen kannst. In so einem Fall hat dmraid die höhere Priorität und schnappt sich die physischen Platten, bevor ein anderer Dienst die Platten ansprechen kann. Das ist auch sinnvoll um eine Beschädigung des (Fake-)RAIDs zu vermeiden.

Wie es dazu kommt, dass auf deinen beiden Platten die Kennung eines nvidia-Fake-RAIDs steht, kann ich von hier im Moment nicht eindeutig beurteilen. Um sicher zu gehen, dass bei unseren Reparaturversuchen nichts schief geht, brauche ich noch mehr Informationen.

Poste bitte mal aus dem korrekt laufenden System (also mit dem alten Kernel) die Ausgaben der Befehle aus meinem letzten Post, aber dann natürlich mit sudo davor, also:

sudo dmraid -r

sudo dmraid -s

sudo blkid

und zusätzlich bitte noch

sudo mdadm --detail --scan

cat /proc/mdstat

Damit kann ich hoffentlich sehen, wie deine Konfiguration im funktionierenden Zustand aussieht.

Zusätzlich würde mich die Vorgeschichte der beiden Platten interessieren. Also:

• Waren die Platten vorher schon mal in einem anderen System eingebaut (An was für einem Controller)?

• Hängen sie im Moment überhaupt an einem nvidia-Controller (Welchen Chipsatz hat dein Mainboard)?

• Du hast ganz sicher kein RAID0 mit den Funktionen des BIOS von Controller oder Mainboard erstellt (vielleicht früher mal zum Testen)?

• Hattest du den Rechner ursprünglich mit 9.04 aufgesetzt oder war das auch schon ein Update?

Falls du die Fragen zur Hardware nicht sicher beantworten kannst, sag mir einfach nur das, was du weißt.

Grüße, ArnoW

Hallo ArnoW,

das sind die Angaben aus dem laufenden System (2.6.28-17-generic):

$ sudo dmraid -r
/dev/sdb: nvidia, "nvidia_abdbeadj", stripe, ok, 488281248 sectors, data@ 0
/dev/sda: nvidia, "nvidia_abdbeadj", stripe, ok, 488281248 sectors, data@ 0

$ sudo dmraid -s
*** Set
name   : nvidia_abdbeadj
size   : 976562432
stride : 128
type   : stripe
status : ok
subsets: 0
devs   : 2
spares : 0

$ sudo blkid
/dev/sda1: UUID="9815454e-f6ea-4b85-8035-3a755a9df322" TYPE="swap" 
/dev/sda2: UUID="22fd0cfb-d1ab-9a1f-944d-545da15d1894" TYPE="linux_raid_member" 
/dev/sdb1: UUID="c77f3d5b-2871-40fa-8046-11c66a97d3f1" TYPE="swap" 
/dev/sdb2: UUID="22fd0cfb-d1ab-9a1f-944d-545da15d1894" TYPE="linux_raid_member" 
/dev/md0: UUID="ddd23006-7c41-4f4d-8094-df3949110eda" TYPE="ext3" 

sudo mdadm --detail --scan
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=00.90 UUID=22fd0cfb:d1ab9a1f:944d545d:a15d1894

$ cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sdb2[1] sda2[0]
      242187776 blocks [2/2] [UU]
      
unused devices: <none>

Übrigens ist die Tage ein neuer Kernel erschienen, mit dem es aber auch nicht geht (zumindest habe ich seit heute morgen 2.6.31-17 und 2.6.31-19 im Grub stehen).

Nun zu deinen Fragen, die ich leider nicht ganz beantworten kann:

• Waren die Platten vorher schon mal in einem anderen System eingebaut (An was für einem Controller)?

Nein, neu im Rechner eingebaut. Es war mal ein Windows im "Lieferzustand" installiert, welches ich aber mit der Linux-Installtion überspielt habe. Es ist übrigens ein DELL OptiPlex 740 Enhanced

• Hängen sie im Moment überhaupt an einem nvidia-Controller (Welchen Chipsatz hat dein Mainboard)?

Mhhh, gute Frage. Das ist ein Arbeitsplatzrechner - den habe ich so hingestellt bekommen. Wie könnte ich das rausfinden? Ich habe hier mal die Ausgabe von lspci gepostet:

$ lspci
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)
03:00.0 VGA compatible controller: ATI Technologies Inc RV610 [Radeon HD 2400 XT]

Hilft das weiter? Hier Informationen zum Processor

$ sudo dmidecode -t processor
# dmidecode 2.9
SMBIOS 2.4 present.

Handle 0x000A, DMI type 4, 35 bytes
Processor Information
	Socket Designation: Socket M2 
	Type: Central Processor
	Family: Athlon 64 X2
	Manufacturer: AMD
	ID: B2 0F 06 00 FF FB 8B 17
	Signature: Family 15, Model 107, Stepping 2
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		MMX (MMX technology supported)
		FXSR (Fast floating-point save and restore)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		HTT (Hyper-threading technology)
	Version: AMD Athlon(tm) Dual Core Processor 4050e
	Voltage: 1.2 V
	External Clock: 1000 MHz
	Max Speed: 3000 MHz
	Current Speed: 2100 MHz
	Status: Populated, Enabled
	Upgrade: Socket 754
	L1 Cache Handle: 0x0010
	L2 Cache Handle: 0x0011
	L3 Cache Handle: Not Provided
	Serial Number:  
	Asset Tag:  
	Part Number:  

$ sudo dmidecode | grep -A3 'Base Board Information'
Base Board Information
	Manufacturer: Dell Inc.
	Product Name: 0YP806
	Version: A01

• Du hast ganz sicher kein RAID0 mit den Funktionen des BIOS von Controller oder Mainboard erstellt (vielleicht früher mal zum Testen)?

Hmm, das RAID, das jetzt läuft, ist das einzige, was hier je eingerichtet wurde. Wenn ich mich recht erinnere haben wir das damals mit einer Alternate-CD eingerichtet.

• Hattest du den Rechner ursprünglich mit 9.04 aufgesetzt oder war das auch schon ein Update?

Der Rechner war mit 8.04 (Hardy Heron) aufgesetzt!!! Ich habe erst kürzlich mit einem schrittweisen Upgrade angefangen, was bis 9.10 auch super geklappt hat.

Danke für die Erläuterungen... Wenn ich es richtig verstehe, könnte es durchaus Sinn machen dmraid zu deinstallieren (oder kann man es irgendwie anders außer Kraft setzen?), weil sich das immer wieder vor mein RAID1 schiebt. Ansonsten bin ich ratlos ...

S.

Hallo sugga,

du hast ein sehr interessantes Setup... ganz im Ernst, ich habe etwas Probleme zu verstehen warum es überhaupt mit irgendeinem Kernel läuft. Aber ich bin fast sicher, dass es nach einer Deinstallation von dmraid mit allen Kerneln läuft.

Zu bedenken ist dabei aber, dass das nur das Symptom kuriert, nicht die Ursache. Meine Vermutung zur Ursache ist, dass das (Windows-)System beim Kauf auf einem RAID0 aufgesetzt war. Dieses RAID0 war (und ist vermutlich immer noch) mit dem Mainboard-BIOS konfiguriert, und wurde von Windows aus mit dem zugehörigen Hersteller-Treiber angesteuert. Die Konfigurationsdaten eines solchen RAID werden irgendwo auf den Festplatten hinterlegt, damit sie nicht verloren gehen. Setzt man nun ein (neueres) Ubuntu auf, wird diese Konfiguration erkannt, und um Datenverlust zu vermeiden, wird dmraid installiert, das damit umgehen kann. Offenbar ist das bei der Installation mit Hardy (noch?) nicht so gelaufen, und du konntest ein MD-RAID1 aufsetzen. Beim Update war es dann damit vorbei...

Um nachhaltig Abhilfe zu schaffen (also die alte RAID-Konfiguration zu entfernen) würde ich vorsichtig und in Schritten vorgehen. Ich habe versucht, meine Vorschläge so zu gestalten, dass das System sehr wahrscheinlich lauffähig bleibt, aber das kann ich aus der Ferne nicht garantieren. Also: Backup von wichtigen Daten machen!

Die Schritte im Einzelnen:

Vorschlag 1: (benutzt das Werkzeug des Herstellers im BIOS um die Konfig zu entfernen, das sollte also funktionieren)

• dmraid vollständig deinstallieren. Befehl:

  sudo apt-get remove dmraid --purge

• Testen, ob das System noch startet (erst mit altem Kernel, danach nochmal mit einem neuen Kernel. Wenn der neue Kernel nicht startet, wird es nicht klappen und du brauchst nicht weiter zu machen!)

• Im Mainboard-BIOS die RAID-Konfiguration suchen und dort das RAID0 (kann auch "Stripeset" oder so ähnlich heißen) löschen. Dabei kriegst du garantiert eine Warnung vor Datenverlust, die musst du ignorieren, wenn es weitergehen soll. In deinem Fall sollte nichts verloren gehen, man weiß aber nie genau, was das BIOS so treibt, deshalb ist das der gefährlichste Schritt. Wenn du dich nicht traust, schau dir meinen Vorschlag 2 an.

• Im Mainboard-BIOS die Betriebsart des Festplatten-Controllers von "RAID" auf "AHCI" stellen (wenn das bei dir anders heißt, oder du unsicher bist, bitte nochmal hier melden)

• Neu starten und sehen...

Vorschlag 2: (kürzer und eventuell ungefährlicher, benutzt aber dmraid zur Entfernung, und dmraid ist laut Entwickler Alpha-Software...)

• System mit altem Kernel starten

• Den Befehl

  sudo dmraid --remove nvidia_abdbeadj

  eingeben. Ich konnte den Befehl hier natürlich nicht testen; bei einer Fehlermeldung mal nur "sudo dmraid --remove" ohne weiteres Argument probieren.

• Startversuch -> geht noch alles? Geht auch der neue Kernel?

• Im Mainboard-BIOS die Betriebsart des Festplatten-Controllers von "RAID" auf "AHCI" stellen (wenn das bei dir anders heißt, oder du unsicher bist, bitte nochmal hier melden)

• Neuer Startversuch -> geht immer noch alles? Falls ja bist du fertig. Wenn du willst, kannst du jetzt noch dmraid deinstallieren, muss aber nicht sein.

Viel Erfolg!

ArnoW

Hi Arno,

ich habe jetzt wieder die Zeit (und den Mut!) deine Vorschläge zu testen.

Vorschlag 2 ist schon mal gescheitert:

xxx@xxx:~$ sudo dmraid --remove nvidia_abdbeadj
[sudo] password for lydia: 

About to delete RAID set nvidia_abdbeadj

WARNING: The metadata stored on the raidset(s) will not be accessible after deletion
Do you want to continue ? [y/n] :y
ERROR: Raid set deletion is not supported in "nvidia" format
xxx@xxx:~$ sudo dmraid --remove

About to delete RAID set nvidia_abdbeadj

WARNING: The metadata stored on the raidset(s) will not be accessible after deletion
Do you want to continue ? [y/n] :y
ERROR: Raid set deletion is not supported in "nvidia" format

Ich wechsle dann zu Vorschlag 1. Wobei ich hier nicht verstehe, an welcher Stelle (beim Booten, alter Kernel, neuer Kernel?) ich dmraid entfernen soll.

Ich probiere es einfach mal, soweit ich komme. Back Up ist gemacht, CD zur Neunstallation liegt bereit!

Ich melde mich wieder, vielen Dank für die Hilfe schon mal! S.

Update 1 [Vorschlag 1] Habe dmraid deinstalliert. Hat geklappt. Er lädt im alten Kernel (2.6.28-17). Alle Daten noch da.

Update 2 [Vorschlag 1] Mittlerweile gibt es ja schon zwei neue Kernels, der ältere (2.6.31-17) lädt nicht aber der neuere (2.6.31-19) . Daten noch da und Sound geht auch wieder

Update 3 [Vorschlag 1] Ich finde die Stelle im BIOS einfach nicht, wo ich die Änderung vornehmen soll... Irgendeinen Tipp? Ansonsten bin ich aber superfroh, dass es bis hier hin wieder funktioniert! Toll! Und sehr sehr vielen Dank für die Hilfe!

Hallo sugga,

sehr schön zu hören, dass es im Prinzip funktioniert hat. Dass dmraid ausgerechnet nvidia-RAIDs noch nicht löschen kann, ist wirklich Pech. Vermutlich ändert sich das mit der Weiterentwicklung des Pakets in der Zukunft mal, aber wann kann man natürlich nicht sagen.

Zu deinem BIOS und seiner Bedienung kann ich dir leider keine Details sagen, da ich es nicht kenne. Wenn du mir die genaue Bezeichnung deines Mainboards mit BIOS-Version nennst, kann ich versuchen, im Netz Infos dazu zu finden.