Installer fuer Lenny wirft Festplatten durcheinander

[micronius]

Hallo,

habe Lenny auf hda (a wie anton) vollstaendig installiert. Nach Entfernung der CD beginnt das Booten mit grub (oder auch mit grub2) von hda voellig normal. Aber dann, wenn der Kernel arbeitet, soll ploetzlich auf hde (e wie emil) zugegriffen werden. Da dort natuerlich nichts Brauchbares vorhanden ist, bleibt der Rechner einfach stehen. Habe Motherboard mit lediglich 1 IDE-Anschluss und benutze deshalb eine PCI-RAID-Steckkarte mit 2 weiteren IDE-Anschluessen, jedoch ohne RAID-Verbund. Die von grub erzeugte menue.lst ist korrekt. Versuche, meine beiden Wechselplatten auf dem Motherboard anders anzuschliessen, blieben leider erfolglos. Wie kann man den Installer bezueglich der Festplattenbehandlung beeinflussen?

MfG, micronius

[dawg]

/boot/grub/device.map ist korrekt?
sonst könntest du versuchen beim grub-screen e (für edit) und, nachdem verändern der optionen, b für boot.
sozusagen try and error.

[micronius]

Hallo dawg,

/boot/grub/device.map enthaelt "(hd0) /dev/hda", ist also o.k.
Ist es moeglich, dass die vom BIOS gelieferten Device-Informationen
von Grub und dem Kernel unterschiedlich interpretiert werden?
In welcher Datei werden Optionen fuer den Kernel abgelegt?

MfG, micronius

[dawg]

Hallo dawg,

/boot/grub/device.map enthaelt "(hd0) /dev/hda", ist also o.k.
Ist es moeglich, dass die vom BIOS gelieferten Device-Informationen
von Grub und dem Kernel unterschiedlich interpretiert werden?
In welcher Datei werden Optionen fuer den Kernel abgelegt?

MfG, micronius

hallo,
ich habe keine ahnung wo die abgelegt werden, tut mir leid.
es kann aber zu unstimmigkeiten kommen, weswegen auch immer (auf der web-seite von grub wird es irgendwo ausgiebig erklärt).
versuch doch spasseshalber ob das vertauschen der einträge in der devices-map was bringt(z.B.hd0 <->hd1). kost ja nix .
viel erfolg und grüsse

[KBDCALLS]

Hallo,

hHabe Motherboard mit lediglich 1 IDE-Anschluss und benutze deshalb eine PCI-RAID-Steckkarte mit 2 weiteren IDE-Anschluessen, jedoch ohne RAID-Verbund.

MfG, micronius

Das könnte/wird nähmlich die Krux sein. IDE 1 ist hda und hdb, Ide 2 hdc u. hdd, Ide 3 hde u hdf usw. Und jenachdem welcher Treiber jetzt zuerst geladen wird werden die Buchstaben durcheinandergewürfelt. Am schnellsten und einfachsten wäre man stellt die menu.lst und fstab auf uuids um.

Das sähe in der Menu.lst so aus, als Beispiel

Code: Alles auswählen

title           Debian GNU/Linux, kernel 2.6.29-2-amd64
root            (hd0,0)
kernel          /vmlinuz-2.6.29-2-amd64 root=/dev/disk/by-uuid/a7b3174e-6d5d-4eb8-afdc-f4631d64e578 vga=0x317 ro
initrd          /initrd.img-2.6.29-2-amd64

Die Zeile muß dann auch entsprechend abgeändert werden Ansonsten wundert man sich warum bei einem Kernelupgrade die alten falschen Einträge wieder da sind. Man braucht nicht die ganze Menu.lst anpassen, das kann man auch manuell machen mit update-grub

Code: Alles auswählen

# kopt=root=/dev/disk/by-uuid/a7b3174e-6d5d-4eb8-afdc-f4631d64e578 vga=0x317 r

Die fstab sieht dann so aus.

Auch nur wieder ein Beispiel

Code: Alles auswählen

# /dev/sda5       /               ext3    errors=remount-ro 0       1
UUID="a7b3174e-6d5d-4eb8-afdc-f4631d64e578"     /       ext3    errors=remount-ro       0       1

Um die UUIDS am bequemsten zu ermitteln.

Code: Alles auswählen

matthias@svetlana:~$ sudo blkid -s UUID
/dev/sda1: UUID="2003ceb6-fd41-4d58-a069-deb0b567ca2d"
/dev/sda5: UUID="a7b3174e-6d5d-4eb8-afdc-f4631d64e578"
....
/dev/dm-0: UUID="862f8911-5708-4461-a217-aa6d9061b8b0"
/dev/dm-1: UUID="ae4c171e-f80f-4eb2-a8a1-55724773a476"
/dev/dm-2: UUID="21f00eb3-d601-4f42-84ce-3650a9417dd6"
/dev/dm-3: UUID="b2177e5d-7672-43c1-b272-10d4e9b7e338"
matthias@svetlana:~$                      

[micronius]

Hallo KBDCALLS,

danke fuer den ausfuehrlichen Tipp! Sind die UUID's device-spezifisch, also PC-unabhaengig und kann ich folglich die UUID's auch an einem zweiten PC ermitteln? Wegen Austauschs des Motherboards laufen auf dem fraglichen, ersten PC naemlich nur CD/DVD-Life-Systeme.

MfG, micronius

[KBDCALLS]

Der sind und Zweck von UUIDs ist ja die ganze Geschichte Deviceunabhängig zu machen. Jede formatierte Partition erhält eine UUID. Die sich ändert sobald neu formatiert wird. Wenn man den Extremfall annimmt aus hda wird sda (was durchaus möglich ist) dann bootet das ganze immer noch. Andernfalls würde der Bootvorgang gegen eine Wand laufen. blkid funktioniert auf jedem Rechner.

[micronius]

wenn die uuid's partitionsbezogen sind, muesste das doch heissen, dass ich meine aus sicherheitsgruenden regelmaessig erstellten festplatten-klone auch mit uuid's unveraendert nutzen koennte, oder ist das ein irrtum?

[micronius]

Ergaenzung zu meiner Frage vom 23.05.2009 / 17:25:05 :

Das duerfte in der Tat ein Irrtum sein, denn bei jedem Klonen werden ja neue Partitionen erzeugt und damit auch neue UUID's. Die UUID hilft daher nur bei der Installation auf eine einzige Festplatte. Wie kann man den Kernel bzw. die Bootroutine veranlassen, Treiber immer in einer bestimmten, von mir ausdruecklich vorgeschriebenen Reihenfolge zu laden? Auch die parallele und damit ggf. willkuerliche Abarbeitung von Tasks hat mich schon in anderen Zusammenhaengen gestoert. Kann man das von vorneherein bereits fuer die Installation ausschliessen?

[Danielx]

Beim Klonen wird die UUID natürlich nicht verändert.

Gruß,
Daniel

[micronius]

Hallo Danielx, hallo KBDCALLS,

so einfach ist das leider nicht. Man muss sich jeweils ansehen, wie die einzelnen Hersteller das "Klonen" durchführen. Acronis zum Beispiel kopiert den Inhalt der gesamten Partition, nachdem die alte gelöscht und eine neue eingerichtet wurde. Beim Neueinrichten entsteht auch eine neue UUID, siehe Beitrag von KBDCALLS vom 23.05.2009 / 13:05:57, während die UUID's im Partitionsinhalt, z.B. in der menue.lst, natürlich unverändert bleiben. Solche "Klone" können nicht als Sicherheitskopie taugen, weil sie nicht lauffähig sein dürften. Deshalb würde ich gerne erfahren, wie man dem Kernel die Reihenfolge der Treiber-Ladevorgänge vorschreiben kann.

MfG micronius

[Danielx]

Acronis zum Beispiel kopiert den Inhalt der gesamten Partition, nachdem die alte gelöscht und eine neue eingerichtet wurde.

Ich habe keine Ahnung was "Acronis" da macht.

Beim Neueinrichten entsteht auch eine neue UUID

Die UUID ist übrigens an das Dateisystem und nicht an die Partition gebunden.

Gruß,
Daniel

[KBDCALLS]

Beim Neueinrichten entsteht auch eine neue UUID

Die UUID ist übrigens an das Dateisystem und nicht an die Partition gebunden.

Gruß,
Daniel

Da hatte ich mich etwas missverständlich ausgedrückt. Die UUID wird natürlich erst vergeben wenn eine Partiton formatiert wird. Man kann beim Formatieren eine UUID angeben. Oder sie nachträglich andern .

[KBDCALLS]

Will man die Reihenfolge der Module vorgeben müßte man an der Initrd schon ansetzen. A man schmeißt das Modul raus was stört , oder was funktionieren könnte in dem Verzeichnis /etc/modprobe.d Legt man eine Textdatei an mit der richtigen Reihenfolge der Module. Und erstellt dann eine neue Initrd.

[habakug]

Hallo!

Es gibt kein "hda" mehr.

This problem can occur when the upgrade of the kernel introduces the use of the new generation of IDE drivers. The IDE disk naming convention for the old drivers was hda, hdb, hdc, hdd. The new drivers will name the same disks respectively sda, sdb, sdc, sdd.

Hier [1] wird es ausführlich erklärt, da auch ein Update diese Probleme mit sich bringt. Kapitel 4.8. System boot hangs on Waiting for root file system / Procedure to recover from /dev/hda that became /dev/sda

Gruß, habakug

[1] http://www.debian.org/releases/lenny/i3 ... ng.en.html

[micronius]

Hallo an alle,

zur Erinnerung: habe auf dem Motherboard 1 IDE-Anschluss, daran 2 Festplatten, außerdem 2 PCI-IDE-Anschlüsse, daran 2 DVD-Laufwerke.

Durch Vergabe von Labeln an die HDD-Partitionen wurde die Lenny-Installation zwar partiell lauffähig, indem hda auf hde umgeleitet wird. Aber es gibt 2 gravierende Fehler:

1.
Beim Booten kapiert fsck (1.41.3 vom Okt. 2008) die Umleitung nicht. Angezeigt wird:
"Filesystem is clean.
Setting system clock.
Cleaning up ifupdown.
Loading kernel modules ... module loaded
done.
Checking file systems ... fsck 1.41.3
Failed to open the device '/dev/hda1': No such file or directory
..."
Angeboten wird Maintenance nach Eingabe des Root-Passworts oder Resume nach Ctrl-D. Wählt man letzteres, geht's normal weiter bis zur KDE-Benutzeroberfläche und der Rechner arbeitet einwandfrei, solange man bei KDE nicht den Benutzer wechseln will. Der Rechner lässt sich auch normal herunterfahren oder neu booten.

2.
Wenn man eine KDE-Sitzung beenden und über KDM einen anderen Benutzer aufrufen will, wird der Bildschirm schwarz und es rührt sich nichts mehr. Es bleibt nur Reset oder Stromabschaltung übrig. In beiden Fällen ist danach das reiserfs-Filesystem nicht sauber und muss an einem anderen PC mit reiserfsck in Ordnung gebracht werden. Ich vermute, dass auch hier /dev/hda1 (Mountpunkt /boot) oder /dev/hda3 (Mountpunkt /) gesucht und nicht gefunden wird.

Weiss jemand Rat, vor allem bei Situation 2. ?

micronius

[habakug]

Hallo!

Das Gerät "hda" ist dein CD/DVD-Laufwerk, das Modul ide-cd(-mod) vergibt diesen Namen. Da ein CD-Laufwerk keine Partitionen kennt, gibt es kein Gerät "/dev/hda1". Du kannst das selbst überprüfen:

Code: Alles auswählen

dmesg | grep hda
dmesg | grep sda

Gruß, habakug

[KBDCALLS]

fsck läßt sich ja nur iritieren wenn ein falsches/nicht existierendes Device noch in der fstab steht. Dann kommt es zu dieser von dir genannten Aufforderung wöhrend des Bootens. Kontrollier das noch mal @micronius

[micronius]

Ja, die fstab war falsch, danke für den Tipp! Jetzt ist Problem 1 gelöst (Booten läuft einwandfrei), aber nicht Problem 2. Die fstab sieht jetzt so aus:

proc /proc proc defaults 0 0
LABEL=wg-rootpart / reiserfs defaults 0 1
LABEL=wg-bootpart /boot reiserfs notail 0 2
LABEL=wg-swappart none swap sw 0 0
/dev/hdb /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

und die Devicebezeichnungen lauten wie folgt (gemäß /var/log/messages):

hdc : ATAPI 32x DVD-ROM DVD-R CD-R/RW drive (Brenner)
hde : ATA DISK drive (Bootfestplatte, erkennbar an hier protokollierter Seriennummer)
hdf : Pioneer DVD-ROM ATAPIModel DVD-115 0108, ATAPI CD/DVD-ROM drive

hda ist also kein CD/DVD-Laufwerk, sondern wird durch die Labelvergabe und die dementsprechende /grub/menu.lst auf hde umgeleitet.

Es bleibt der Fehler, dass kein direkter KDM-Benutzerwechsel ohne Reboot möglich ist (schwarzer Bildschirm mit Rechnerstillstand). Die Log-Dateien in /var melden leider nichts Verdächtiges. Wo kann man weiter ansetzen?

Gruss, micronius

[micronius]

Hallo habakug,

an 2009-05-25 / 17:28:02 hattest Du u.a. geschrieben: "Es gibt kein 'hda' mehr."
Mag sein, bei mir existieren hda, hdb, hdc, hdd und hde beim Booten und beim Upgrade aber leider teilweise immer noch. Das hat zur Folge, dass ich mit apt-get dist-upgrade zwar die meisten Sicherheitslöcher stopfen kann, aber der Kernel selber lässt sich nicht aktualisieren, weil in der Tat /root/dev nicht gefunden wird. Diese Inkonsequenz sehe ich als Fehler der Entwickler an und schreibe ihnen dazu jetzt einen Fehlerbericht, denn ich sehe selber keine Möglichkeit, diese Blockade zu umschiffen. Installations- und Upgrade-Prozeduren sollten damit rechnen, dass hda statt auf sda auf hde liegen kann.

Gruß, micronius

[KBDCALLS]

Wenn man den die fstab und die menu.lst konsequent auf UUIDs anpasst. Dann können einem wechselnde Devices nicht mehr schocken und vor einem vermeintlich unbootbarem System kapitulieren lassen.

[micronius]

Hallo KBDCALLS,

hier meine fstab:

Code: Alles auswählen

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc                    /proc           proc     defaults        0       0
LABEL=wg-rootpart       /               reiserfs defaults        0       1
LABEL=wg-bootpart       /boot           reiserfs notail          0       2
LABEL=wg-swappart       none            swap     sw              0       0
/dev/hdb        /media/cdrom0   udf,iso9660      user,noauto     0       0
/dev/fd0        /media/floppy0  auto             rw,user,noauto  0       0

Und hier meine /boot/grub/menu.lst:
.......

Code: Alles auswählen

title		Debian GNU/Linux, kernel 2.6.26-2-amd64
password ......
root		(hd0,0)
kernel		/vmlinuz-2.6.26-2-amd64 root=UUID=8e1b2e49-3dfb-4942-8eb6-9868733c5d15 ro splash=verbose
initrd		/initrd.img-2.6.26-2-amd64

Bin gespannt, was daran inkonsequent sein soll.
Der Installer arbeitet damit nämlich einwandfrei, aber der Kernel-Upgrader kapiert die Umleitung von hda auf hde nicht.

Gruß, Micronius

[KBDCALLS]

Das wichtigste and der menu.lst hast du leider vergessen. Poste sie mal komplett nach NoPaste

[micronius]

22539 menu.lst

[KBDCALLS]

Bin mir nicht ganz sicher ob Grub das so akzeptiert.wie du das geschrieben hast. Genauer genommen das Script update-grub

Bei mir sie die kopt Zeile so aus.

Code: Alles auswählen

# kopt=root=/dev/disk/by-uuid/a7b3174e-6d5d-4eb8-afdc-f4631d64e578

Du mußt deine richtige UUID eintragen dann funktioniet das auch. Das ist übrigens kein Kommentar, auch wenn es so ausieht.

Was zwischen diesen Zeilen

Code: Alles auswählen

## ## Start Default Options ##
...
...
## ## End Default Options ##

steht und mit einem Kommentarzeichen # beginnt wird vom Script update-grub ausgewertet.

PS: Die deine menu.lst sollte du bitte nach NoPaste posten. Siehe Punkt 2.6 der Verhaltenregeln.