[Debian] [RAID1] [LVM] [GRUB] System bootet nach Installation nicht

[Debian] [RAID1] [LVM] [GRUB] System bootet nach Installation nicht (101 Beiträge, 1021 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi!

Ich versuche nun schon den ganzen Tag Debian basierend auf einen Software Raid 1 zu installieren.

Hardware:
2 x 2 TB SATA Platten

Partitionierung:
LVM VG SYS, LV HOME - 100.0 GB LINUX device-mapper (linear)
Nr.1 100 GB K ext3 /home
LVM VG SYS, LV ROOT - 200.0 GB LINUX device-mapper (linear)
Nr.1 200 GB K ext3 /
LVM VG SYS, LV VAR - 1.3 TB LINUX device-mapper (linear)
Nr.1 1.3 TB K ext3 /var
LVM VG SYS, LV USR - 200 MB LINUX device-mapper (linear)
Nr.1 200 MB K ext3 /usr
RAID1 Gerät #0 - 2.0 TB Software-RAID-Gerät
Nr.1 2.0 TB K LVM
SCSI1 (0,0,0) (sda) - 2.0 TB ATA ST32000542AS
Nr.1 200 MB B K ext3 /boot
Nr.2 2.0 TB K raid
SCSI1 (0,0,0) (sdb) - 2.0 TB ATA ST32000542AS
Nr.1 2.0 GB F Swap Swap
Nr.2 2.0 TB K raid

Das System lädt nicht mal Grub

Bei "/boot" ist das boot-flag gesetzt. Grub installier ich auf "/dev/boot". Wärend der installtion gab es keine Fehler.

Wo liegt der Hund begraben? "/boot" ist außerhalb des Arrays ...
Hab auch schon versucht Grub in den MBR zu installieren mit dem selben Ergebniss (was mir eigentlich noch klar erscheint) aber warum wird Grub nicht gestartet, obwohl das boot-flag gestzt ist?

Help!

LG,
Nick

10.08.2010, 12:55 Uhr - Editiert von n256, alte Version: hier

Das System lädt nicht mal Grub

Steht denn irgendwas da oder findet es gar keinen MBR oder wie oder was?

$$$ Löschen statt Verstecken! $$$

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Er findet keinen MBR wenn man das so sagen kann ... "no bootable device" bootreihnfolge passt ...

08.08.2010, 22:55 Uhr - Editiert von n256, alte Version: hier

Ich weiß nicht was der Debian Installer macht, ich installiere sowas immer manuell.

In deinem Setup ist zumindest schonmal ein Konzeptfehler drin den du korrigieren solltest, du nutzt derzeit nicht RAID für Boot und Swap obwohl das ohne weiteres möglich ist. Es ist auch notwendig, wenn die Maschine weiterlaufen und noch booten können soll, wenn eine Platte stirbt. Das ist ja gerade das schöne an RAID1, es spiegelt, eine Hauptplatte gibt es in dem Sinne nicht.

Wie gesagt mit dem Installer kann ich dir gar nicht helfen aber die manuelle Vorgehensweise ist aus dem Kopf etwa so:

- Platte A partitionieren (cfdisk /dev/sda)
- Partitionstabelle auf Platte B duplizieren (sfdisk -d /dev/sda | sfdisk /dev/sdb)
- Für jede Partition RAID1 einrichten (mdadm --create --schlagmichtot, jedenfalls RAID1 mit Superblock 0.9)
- RAID-Devices formatieren (mkfs, mkswap, pvcreate, schlagmichtot)
- Debian installieren (debootstrap oder irgendwie mit dem Installer)
- Grub installieren und zwar auf beide Platten mit der jeweiligen Platte als hd0. (grub, device (hd0) /dev/sda, root (hd0,0), setup (hd0), dann dasselbe nochmal mit device (hd0) /dev/sdb)
- booten
- freuen

Ach ja, für LVM lege ich gerne mehrere Partitionen (und damit auch mehrere RAIDs) an, auch wenn das später ja eh wieder von LVM zusammengefasst wird. Es hat den Vorteil, daß bei einem temporären Fehler (z.B. Wackelkontakt am Kabel oder ähnliches), dann nicht gleich ein ganzes riesengrosses 2TB RAID auseinanderfällt und komplett neu gesynct werden muss, sondern nur ein kleineres Teilstück davon.

Nachteil ist daß man bei einem tatsächlichen Ausfall, etwas mehr Arbeit hat alle RAIDs neu einzurichten, wobei man das auch wieder wegautomatisieren kann, bash kann schließlich loops.

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Erstmal danke für die manuelle vorgehensweise.
Ich dachte ebben auch das ich boot ebeso im array lassen kann, da dies eben nicht funktioniert hat habe ich es nach älteren anleitungen im netz eben außerhalb positioniert.
Was auch komisch ist dass das system im rescue mode die einhãngepunkte nicht findet, sprich er zeigt mir zwar alles an jedoch eben nicht mit den dazugehörigen einhãngepunkte.

Es mûsste jedoch grundsätzlich mit der oben geschriebenen konfiguration funktionieren oder? Sollte sich nicht etwas anderes ergeben werde ich morgen die manuelle methode versuchen ... ist alles seh mühsam da die installation immer dauert... bin schon kurz davor auf das raid zu verzichten und die platten per script alle 24 stunden zu spiegeln ...

Sorry für tippfehler ... schreib grad übers mobiltelefon

Hi!

Also ich hab jetzt für jeden einhängepunkt ein Raid 1 gemacht.
Jetzt wollte ich grub über den rescu mode installieren jedoch bekomme ich bei "root(0,0)" immer die fehlermeldung "System type unknown, partition type 0xee".

Partition Type ee ????


 0  Empty           1e  Hidden W95 FAT1 80  Old Minix       be  Solaris boot
 1  FAT12           24  NEC DOS         81  Minix / old Lin bf  Solaris
 2  XENIX root      39  Plan 9          82  Linux swap / So c1  DRDOS/sec (FAT-
 3  XENIX usr       3c  PartitionMagic  83  Linux           c4  DRDOS/sec (FAT-
 4  FAT16 <32M Venix OS hidden C c DRDOS sec FAT Extended PPC PReP Boot Linux extended c Syrinx FAT SFS NTFS volume set da Non FS data HPFS NTFS d QNX x NTFS volume set db CP M CTOS AIX e QNX x nd part Linux code/>ee  EFI GPT
10  OPUS            55  EZ-Drive        a6  OpenBSD         ef  EFI (FAT-12/16/
11  Hidden FAT12    56  Golden Bow      a7  NeXTSTEP        f0  Linux/PA-RISC b
12  Compaq diagnost 5c  Priam Edisk     a8  Darwin UFS      f1  SpeedStor
14  Hidden FAT16 <3 61  SpeedStor       a9  NetBSD          f4  SpeedStor
16  Hidden FAT16    63  GNU HURD or Sys ab  Darwin boot     f2  DOS secondary
17  Hidden HPFS/NTF 64  Novell Netware  b7  BSDI fs         fd  Linux raid auto
18  AST SmartSleep  65  Novell Netware  b8  BSDI swap       fe  LANstep
1b  Hidden W95 FAT3 70  DiskSecure Mult bb  Boot Wizard hid ff  BBT
1c  Hidden W95 FAT3 75  PC/IX

Das ist eine EFI-Gschicht ???
Ist das ein Appleteil oder wie kommt das ???
Hast du selbst den Typ ee ausgesucht ?
Windows kann damit umgehen ?

Wenn er schon die ganze Zeit GPT Partitionen hatte, erklärt das seine Probleme...

Die gängige Grub Version (Grub 1 bzw. 0.x) unterstützt GPT nicht und kann davon nicht booten. Das hätte dann aber auch schon die ganze Zeit diesen Fehler bei der Installation werfen müssen.

Wie es mit LILO aussieht, weiß ich nicht. Theoretisch könnte LILO ja funktionieren da sich LILO auch um Dateisysteme nicht kümmert, aber ich meine, die Partitionstabelle schaut es sich doch an. Oder liege ich da falsch?

Ansonsten das neue Grub 2, das auch GPT fähig ist.

Oder eben die guten alten DOS Partitionen verwenden, sofern das mit 2TB noch geht.

Wenn er schon die ganze Zeit GPT Partitionen hatte, erklärt das seine Probleme...

Aber er schrieb doch, dass sich WindowsXP out-of-the-box dort installieren ließ... Kann das echt damit umgehen ? Das ist ja älter als der EFI-Kram, oder ? Da passt doch irgendwas nicht...

Wenn er Windows installiert hat wird Windows die Platte ja nochmal selber anders partitioniert haben als er das getan hat bei der Linux-Install... da muss das eine ja nicht mit dem anderen zusammenhängen...

Aber "normales" XP konnte doch nicht von EFI booten - EFI gab's ja damals noch gar nicht... und laut ihm war es aber XP, dass davon booten konnte...

UNKLAR.

Ob du DOS oder GPT Partitionierst ist ja dein Ding, das hat ja mit dem System nichts zu tun...

Doch:
http://www.heise.de/newsticker/meldung/Windows-XP-auf-Linux-Umwegen-fuer-Intel-iMacs-178203.html

... berichten Experimentatoren von "Mac OS X Internals" nun von dem erfolgreichen Start einer Knoppix-Distribution auf dem iMac. Während Windows XP wegen der fehlenden Unterstützung des Extensible Firmware Interface (EFI) nicht auf den iMacs läuft, konnten die drei beteiligten Entwickler das Microsoft-Betriebsystem unter VMware zum Laufen bringen.

Der XP-Bootloader dürfte mit EFI nichts anfangen, nehme ich da mit...

Zusammenhang?! Hat er nen Mac?

EFI-GPT Partitionstabelle kannst du wenn du willst auch am PC benutzen... der Debian Installer macht das vielleicht von sich aus weil er eine 2TB Platte sieht, Windows XP macht das aber ganz sicher nicht.

D.h. wenn er Debian installiert hat er GPT-Partitionen,
und wenn er Windows installiert ganz normale DOS-Partitionen.

Über die Hardware ist da noch lange nichts gesagt.

Zusammenhang:
Wie man aus dem Artikel lesen kann (zumindest habe ich es so gelesen) kann man Windows nicht von EFI-Teilen (die halt mit dem Mac kamen) booten...

Ergänzung: Findet sich auch hier:
http://de.wikipedia.org/wiki/Extensible_Firmware_Interface

Die ausschließliche Nutzung des EFI ohne den optionalen BIOS-Kompatibilitätslayer verhinderte zunächst das Booten von Windows XP auf Intel-basierten Macintosh-Rechnern.

Und JA, ich glaube, er hat einen Mac - oder kennst Du sonst ein Trum in der PC-Welt, dass mit EFI daherkommt ???

14.08.2010, 08:42 Uhr - Editiert von kombipaket, alte Version: hier

Ich gebs auf.

NEIN, ich versuche es mal

1.) Wenn du ein normales BIOS hast, dann wird der Bootloader ab Position XYZ geladen. Der setzt dann BIOS-Calls ab - und lädt den Rest nach.

2.) Wenn du aber EFI hast - dann hast EFI _anstelle_ des BIOS.
Das bedeutet, dass ein Bootloader, der BIOS-Calls absetzen will (weil er EFI nicht kennt) ins leere laufen muss.

Genau dieses Problem hatte natürlich auch WindowsXP - weil der mitgelieferte Loader eben nicht mit EFI umgehen kann... Und genau drum führte bei den Apple-Rechnern ja bootcamp quasi den Glue dazwischen ein.

Wenn aber ein hundsordinäres WindowsXP out-of-the-Box von seinem Rechner booten kann, kann es sich logischerweise _nicht_ um eine EFI-Gschicht handeln... Weil dann auf die abgesetzten int80 keine Antwort kommen kann, wenn kein BIOS da ist.

EFI ist _mehr_ als nur eine andere Plattenstruktur - IMHO.

> EFI ist _mehr_ als nur eine andere Plattenstruktur - IMHO.

Ja, aber das hindert dich nicht daran, die Platten trotzdem mit GPT zu partitionieren. Das kannst du auf jedem ollen Rechner machen und der Debian Installer macht anscheinend gerade das. Bei großen Festplatten hat man dann eh keine Wahl mehr da das DOS Partitionsschema nicht mehr als 2TB unterstützt.

Ich habe auch GPT Partitionen auf einer Festplatte und dazu ein ganz normales PC BIOS.

Und um mehr als die Partitionstabelle gings ja nicht, sein Grub hat sich beschwert daß auf der Festplatte eine GPT Partitionstabelle ist, die kannst du mit parted auf jedem noch so ollen Rechner draufmachen, mit dem Bios hat das erstmal gar nichts zu tun.

Die Frage was das Mainboard / BIOS damit anstellt wird erst interessant wenn man davon booten können will. Wobei das dank Legacy MBR auch auf alten Systemen klappen sollte wenn man einen Bootloader hat der sich direkt ins MBR setzt. Was Grub (2) ja macht.

Ich gehe davon aus, daß sein Windows XP natürlich ganz normale DOS Partitionen benutzt hat, der Debian Installer ihm aber warum auch immer eben GPT Partitionen draufhaut.

Der ganze Faden hier ist sowas von unnötig, wenn er sich gleich an meine manuelle Anleitung gehalten hätte, dann hätte er stinknormale DOS-Partitionen drauf (geht bei 2TB ja gerade noch so) und das Ding würde einfach laufen. Mit Grub, Raid, und Debian. Und gelernt hätte er auch noch was dabei...

Mit dem Installer geht es sicher auch zu machen, ich benutz den nur nie, entsprechend weiß ich nicht an welchen Knöpfen man da beim Installer drehen kann/muss, oder was er im Installer falsch macht...

So, und das war's jetzt.

Ja, aber das hindert dich nicht daran, die Platten trotzdem mit GPT zu partitionieren. Das kannst du auf jedem ollen Rechner machen und der Debian Installer macht anscheinend gerade das. Bei großen Festplatten hat man dann eh keine Wahl mehr da das DOS Partitionsschema nicht mehr als 2TB unterstützt.

Und genau hier wichen wir ab.
- Du glaubst, dass der Installer fehlerhafterweise eine GPT draufklatscht, obwohl es ein normaler BIOS-Rechner ist.
- Ich glaubte, dass es sich um ein EFI-Trum handelt, weil ich noch nie gesehen habe (und ich habe oft Debian wo installiert), dass da fehlerhafterweise eine GPT drauf landet.

Allerdings:
Ich habe keine Platten größer 1TB....

Ganz offensichtlich stimmt dein Ansatz, dass man für start/end-Sector ja nur 4 Byte zur Verfügung hat - und ganz klar ergeben sich daraus gerade adressierbare 2TB.

GPT (von dem ich keine Ahnung hatte) macht also durchaus Sinn.
Weil er eh mitliest:
http://www.tauceti.net/roller/cetixx/entry/partitionen_mit_mehr_als_2
klingt nach ihm.

Danke jedenfalls für deine Info!

14.08.2010, 12:12 Uhr - Editiert von kombipaket, alte Version: hier

Hi!

Nein eigentlich sind alle Partitionen als ext3 Formatiert.
Wieso Windows?

EDIT:
Bei der Grub installation bin ich schon so weit drauf gekommen das ich die Fehlermeldung "Die Partiton ist nicht aus dem BIOS ansprechbar" bekommen habe.

Wenn ich /boot außerhalb des Raid mache und die Partition als "BIOS bereich resavieren" im Partitionsmanager makiere funktioniert es.

Bleib das Problem das /boot nicht im Array ist.

12.08.2010, 13:14 Uhr - Editiert von n256, alte Version: hier

Wenn ich /boot außerhalb des Raid mache und die Partition als "BIOS bereich resavieren" im Partitionsmanager makiere funktioniert es.

Diese Einstellung triffst Du im BIOS, oder ???
Hast schon probiert, LILO wieder draufzuklatschen mit Raid ?

Nein eigentlich sind alle Partitionen als ext3 Formatiert.

Ein Filesystem hat ja nun nichts mit dem Partition Type zu tun...

Wieso Windows?

Mich irritiert, dass du geschrieben hast, dass Windows XP davon booten kann...
Meines Wissens konnte das nicht von EFI booten.

Und um es jetzt echt abzuschließen:
EFI - JA oder NEIN ????

Ergänzung: Wenn EFI - dann brauchst den elilo, glaub ich.

12.08.2010, 14:56 Uhr - Editiert von kombipaket, alte Version: hier

*überfordert*

Hm, als ich habe WinXp installiert und da konnte ich eben WinXP booten.
EFI hab ich in meinem Leben noch nie gehört daher kannich dir da leider keine Auskunft geben. Aver ich habe mich zu früh gefreut, auch wenn /boot außerhab des Arrays ist bootet das System nicht.

Ok da hats echt was gröbers ... Er bootet nichtmal eine normale Debian Installation ....

Wie / womit hast du denn partitioniert?

In meiner manuellen Anleitung ging ich von DOS Partitionstabellen aus, cfdisk / sfdisk macht auch nichts anderes. Du scheinst jetzt bei GPT gelandet zu sein oder zumindest deutet die Fehlermeldung darauf hin.

Mit GPT ist die Bootgeschichte etwas komplizierter da die alten Bootloader (LILO und GRUB) das nicht kennen, da brauchste gepatchte oder einfach neuere Versionen davon (Grub 2).

Ich dachte eigentlich daß DOS Partitionstabellen noch bis 2TB gehen und erst darüber dann GPT fällig wird.

Hm, ich hab mit dem Partitonsmanager von der Debain installation gearbeitet.
Ich Formatiere mal die Platten mit dem Windows installer und probiers dann nichmals. Vill. hab ich die Platten durch die vielen versuche "zerschossen"

Um die Platten zu resetten brauchst eher nur ein dd if=/dev/zero of=/dev/sda bs=1M count=1, selbiges für sdb. dann ist der boot sektor und die partitionstabelle tot, und mehr braucht man da nicht. schau doch mal im debian installer ob man da nicht auswählen kann ob der dos oder gpt partitionstabellen nutzt. gpt ist ja an sich auch kein Problem, du brauchst nur modernere Bootloader dafür (Grub 2 oder kA was es da auf Lilo Seite gibt).

Meine manuelle Anleitung vorher bezieht sich halt auf das gute alte DOS Schema (da ist halt bei 2TB dann Schluss, größer geht nicht), cfdisk / sfdisk machen auch nichts anderes, für GPT brauchst du gdisk oder besser parted.

Falls du irgendwo einen alten USB-Stick noch herumliegen hast, kannst ja übergangsweise auch den zum Booten nehmen. Mehr als 64MB brauchst du nicht für Grub und ein zwei Kernel. Dann dürfen die Partitionen gerne GPT sein und du kannst dich dann aus dem laufenden System heraus ganz in Ruhe um einen GPT-fähigen Bootloader bemühen.

http://wiki.debian.org/Grub#Configuringgrubv2 oder sowas in der Art

Mit Grub 2 kenne ich mich leider selbst nicht aus, noch nie benutzt.

Hi!

Dankw hat geholfen!

Aber es scheint unmöglich zu sein Grub2 oder Lilo auf einem soft-raid mit lvm zu installieren. Da mir der Installer immer wieder GPT auf die Platten macht hab ich es jetzt schon in hundert Varianetn mit Grub2 versucht. Leider bekomme ich immer wieder die Meldung "Core image ist too big"

Vielleicht das da:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504752
http://grub.enbug.org/BIOS_Boot_Partition

Blocklisten sollten auch gehen, aber dann hast du das gleiche Problem wie LILO - Neuinstallation nach jeder Dateiänderung erforderlich.

Hmmm... Das bedeutet, dass er 3 Partitionen braucht, oder ?

Eine kleine für sudo parted /dev/sda set bios_grub on
Eine für md0 - /boot
und eine für md1 - LVM

oder ? Und grub halt manuell auf beide sd? installieren ?

Oder könnte das wieder mit LILO auch klappen ?

Ich bin sowieso verwirrt, wieso er nicht gleich davon gesprochen hat, dass er ein EFI-System hat

Weil ers nicht wusste

Bin inzwischen so weit das ich die Meldung

no boot signature on partition
no boot signature on partition

bekomme. Soweit ich erroriert habe kommt das von lilo.
(Möchte jetzt versuchen lilo zum laufen zu bringen)

Lilo will ständig auf /dev/md1 (root) installieren also hab ich das mal gemacht. Siehe da einen Schritt weiter ... auf /dev/md0 (boot) wiegert sich lilo.
Ich habe jetzt für die einhängepunkte / /home /usr /boot /var jeweils ein eigens raid 1 erstellt.

Jetzt stehe ich vor dem nächsten Problem, denn liloconfig lässt sich nun im rescue mode nicht starten:

depconf: DbDriver "config": could not open /var/cache/debconf/config.dat"

Auf /var ist plötzlich nur noch /var/run/ und /var/lock/.

EDIT: /var war trotz "mount -a" und in der fstab stehend nicht gemounted
In run ist eine Datei namens mdadm.map.new mit 0 bytes.

Aber was anderes:

luna:/var# liloconfig
Soll ein Boot-Block mit Ihrer aktuellen LILO-Konfiguration installiert werden? [J/n]
Using BIOS device code 0x80 for RAID boot blocks
Reading boot sector from /dev/md1
Fatal: map file must be on the boot RAID partition

Dann bleibt er hängen.
Auf /boot liegt nun ein File "map~" mit 0 byts

14.08.2010, 01:02 Uhr - Editiert von n256, alte Version: hier

Raid-Syncs laufen im Hintergrund, du kannst währenddessen ganz normal auf die Daten zugreifen. Ich klink mich hier mal aus und lass dich weiter basteln... Viel Erfolg

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Tag 8, Lilo funkitioniert!
Jedoch erhalte ich beim startup nun die Fehlermeldung:
kernel panic not syncing vfs unable to mount root fs on unknown wn-block(1,0)

Meine Lilo.conf sieht nun so aus:
boot=/dev/md0
raid-extra-boot=/dev/sda,/dev/sdb
prompt
map = /boot/System.map
timeout = 30
delay = 30
default=Linux

image=/boot/vmlinuz-2.6.26-2-686
        label=Linux
        read-only
        root=/dev/md1

Habt Ihr eine Idee?

PS.: Bis jetzt hat mich eure Hilfe wirklich weit gebracht! Danke nochmals!

14.08.2010, 15:19 Uhr - Editiert von n256, alte Version: hier

Du brauchst entweder ein initramfs das dir dein RAID zusammenbaut wenn der Kernel bootet,

oder du musst einen Kernel so compilieren daß er es selber macht (RAID autodetect).

Ich bevorzuge letzteres weils so schön einfach ist und weil ich meinen Kernel ja eh selber baue. Funktioniert aber nur wenn das RAID mit Superblock 0.9 erstellt ist und nicht mit 1.0 oder sowas...

Aber der Debian offizielle Weg ist wohl das initrd / initramfs das von Debian erzeugt wird. Wie man ein Initramfs von Hand selber bastelt weiß ich, wie es von Debian gemacht wird weiß ich nicht.

Hat das denn nie ein Ende

Ich schau mal obs mir gelingt ... hab jetzt schon meinen ganzen Urlaub damit verbracht ....

Hi!

Ok, hab also initramfs erneuert (weil schon installiert):

luna:/var# dpkg-reconfigure linux-image-2.6.26-2-686
luna:/var# zcat /boot/initrd.img-2.6.26-2-686 | cpio -i

Hab die lilo.conf abgeändert auf:

luna:/var# cat /etc/lilo.conf
boot=/dev/md0
raid-extra-boot=/dev/sda,/dev/sdb
prompt
map = /boot/System.map
timeout = 30
delay = 30
default=Linux

image = /boot/vmlinuz-2.6.26-2-686
        label = Linux
        root = /dev/ram0
        initrd = /boot/initrd.img-2.6.26-2-686
        append = "real_root=/dev/md1"
        read-only

Beim Startup passiert folgendes:

...
Begin: Waiting for root file system ... done.
Begin: Running /scripts/local-premount ... kinit: name_to_dev_t(/dev/sda4) = sda4(8,4)
kinit: trying to resume from /dev/sda4
[  197.338294] PM: Starting manual resume from disk
kinit: No resume image, doing normal boot ... done.
mount: mounting /dev/root on /root fiald: No such device
Begin: Running /scripts/local-bottom ...done.
done.
Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed : No such file or directory
done.
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
Target filesystem doesnt't have /sbin/init.
No init found. Try passing init= bootarg.

BusyBox v1.10.2 (Debain ....

Hab ich was verpasst? Warum versucht er diese ganzen falschen mounts?
In den Anleitungen die ich gefunden habe steht nichts von scripts o.ä.
Und woher bekommt er die Information das es ein sda4 gäbe?

14.08.2010, 20:54 Uhr - Editiert von n256, alte Version: hier

Hast du was komisches (z.B. /dev/root) in deiner /etc/fstab stehen?

Nö eigentlich nicht:

sh-3.2# bash
root@luna:/# su
luna:/# export TERM=vt100
luna:/# cat /etc/fstab
proc /proc proc defaults 0 0
/dev/md1 / ext3 errors=remount-ro 0 1
/dev/md0 /boot ext3 defaults 0 2
/dev/md2 /home ext3 defaults 0 2
/dev/md3 /var ext3 defaults 0 2
/dev/sda4 none swap sw 0 0
/dev/sdb4 none swap sw 0 0
/dev/sdc0 /media/cdrom udf,iso9600 user,noauto 0 0
devpts /dev/pts devpts

Ja sda4 und sdb4 sind swap partitons, aber sonst ....

EDIT: Neues Problem!
Kann nicht mehr im rescue mode auf /dev/md1 arbeiten!
Laut df sind alle einhängepunkte hundertmal gemountet.
umount -a funktioniert auch nicht! umount2: Wrong parameter

14.08.2010, 22:13 Uhr - Editiert von n256, alte Version: hier

Auch nach einer neuinstalltion das selbe Problem.
Er lößt die mounts beim Shutdown im rescue mode nicht mehr.

Ich kann zwar auf / arbeiten und ein ls machen jedoch nimmt er mir keine commands mehr an

Gibt es eine möglichkeit alle mounts ohne umount zu lösen?

Alt+SysRQ(PrintScreen)+U

Denken wir mal gemeinsam nach.

1. Du hast ein Software Raid. Sprich, Dein Kernel kann da hergehen und die beiden Platten "verheiraten", softwareseitig. Hoffentlich fix in den Kernel einkompiliert und nicht als Modul, weil ansonsten stirbst dort gleich wieder sofern Du das Problem mal gelöst hast.

2. Dein Bootloader ist auf diesem softwarebasierten RAID installiert.

Quizhauptfrage: Wie soll der Kernel, der logischerweise NACH der Bootmaschine geladen wird, das RAID für GRUB aufbauen damit GRUB sich überhaupt mal selbst finden kann?

Lösung dafür hab ich jetzt keine die Dich zufriedenstellen wird. Entweder Du bootest von einer Platte oder Du organisierst Dir 'nen Raidcontroller der mit Deinem Kernel kann.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

09.08.2010, 11:32 Uhr - Editiert von Fly, alte Version: hier
Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Genau drum verwende ich gerne lilo...

Einfach folgendes aktivieren, wenn /boot unter md0 hängt:

boot=/dev/md0
root=/dev/md0
raid-extra-boot=mbr-only

Und lilo schreibt brav bootcode für alle mds...

In der initrd nimmst dann eh brav dein Raid hoch und bootest weiter.

Deine Quizhauptfrage verstehe ich jedenfalls nicht:

Wie soll der Kernel, der logischerweise NACH der Bootmaschine geladen wird, das RAID für GRUB aufbauen damit GRUB sich überhaupt mal selbst finden kann?

Wieso sollte der Kernel ein RAID für Grub aufbauen ?
Grub soll ja nur (per BIOS-Calls) den Kernel laden, danach die initrd - und die Kontrolle an den Kernel übergeben. In der Initrd wird dann halt das Raid aufgebaut - und der Kernel kann die Kontrolle im Anschluss an /sbin/init (oder was auch immer) übergeben.

Software-Raid klappt sehr fein unter Linux - inklusive dem Booten davon (solange /boot halt unter RAID1 ist).

09.08.2010, 11:44 Uhr - Editiert von kombipaket, alte Version: hier

Sorry, übersehen dass es 'n 1er RAID ist.

Da sollt's dann aber so oder so keine Probleme geben.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Danke!

Leider klappt es so nicht aus welchen Gründen auch immer ...
Ich setzte das System gerade neu auf um eben boot wieder ins array zu werfen, aber der installer löscht jetzt schon seit geschlagegen 5 Stunden den RAID 1 Verbund, da ich leider sonst nicht weiter Partitionieren kann

09.08.2010, 14:44 Uhr - Editiert von n256, alte Version: hier

Bei grub kann ich Dir nicht helfen - bei LILO würdest boot= und root= wie oben geschrieben setzen...

Klatsch Dir spasseshalber den LILO drauf und berichte.

Ach ja:
LILO mag mit BIOS-Calls booten, bei GRUB kann ich es nicht sagen.
Kann es sein, dass du einen Plattencontroller hast, der sich nicht ins Bootbios reinhängt ??? Wenn ja, müsstest das in der Controller-Config umstellen.

Is ein Software-Raid

09.08.2010, 18:17 Uhr - Editiert von n256, alte Version: hier

Ich versteh' nicht, was deine Antwort mit meinem Posting zu tun hat ???

Hi!

Ich dachte das du mit "Plattencontroller" einen Raid-Controller meinst.
Ich verwende die onboard controller.

Argl.

Hast du schon überprüft, ob die onboard-Controller ein Booten via BIOS zulassen ???
Ich glaube, dass dein Rechner nix bootet, was auf der Platte installiert ist

Hi!

Was meinst du mit Booten via Bios?

Dein Controller muss sich ins BIOS einblenden - typischerweise gibt es da Optionen im BIOS dafür.

Sorry, ich versteh das immer noch nicht ...
Ich kann im BIOS einstellen wie SATA behandelt werden soll und etc ...

Aber wie meinst du eingeblendet?

Kannst Du WIndows von den Platten booten, wenn Du es installierst ?

Hi!

Wie kann ich das Bootflag für /boot das ich im RAID 1 ud im LVM SYS befindet setzen? Oder ist das hier nicht nötig?

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Das bootable-Flag ist einem Linux-Loader uuuuur wurscht...
Man setzt es üblicherweise, damit man bei einem fdisk -l gleich mal sieht, von wo gebootet wird - es ist dem System aber echt egal.

So hab jetzt wieder /boot im RAID 1 und im LVM. LILO ist auf /dev/md0 installiert. Aber leider immernoch "No bootable device"

09.08.2010, 18:18 Uhr - Editiert von n256, alte Version: hier
Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Also, LILO traue ich nicht weiter als ich es werfen kann. Verwende ich nicht mehr, seit ich weiß, daß es GRUB gibt...

Aber davon, daß man den Bootloader ins RAID-Device installiert, habe ich noch nichts gehört.

Der Bootloader muss ja in jedem Fall an den Plattenanfang, also im Prinzip noch vor die Partitionstabelle. Wenn das RAID dann erst auf den Partitionen selber anfängt, kann das übers RAID-Device nicht funktionieren.

Die Methode die ich vorher beschrieben habe funktioniert auf jeden Fall,

wenn du es irgendwie anders gemacht hast kannst du zumindestens noch GRUB manuell installieren, solange wenigstens die Boot-Partition auf den Platten einzeln ansprechbar ist. Was der Fall ist wenn du das RAID richtig aufgesetzt hast.

Zum Boot-Zeitpunkt ist das RAID ja wurst egal, der Bootloader muss starten, und der Bootloader muss den Kernel laden können. Um das RAID kümmert sich dann der Kernel, wenn er erstmal geladen ist.

Also, LILO traue ich nicht weiter als ich es werfen kann. Verwende ich nicht mehr, seit ich weiß, daß es GRUB gibt...

So geht es mir mit GRUB. Ein Bootloader, der Filesysteme kennen muss - krank.

Aber davon, daß man den Bootloader ins RAID-Device installiert, habe ich noch nichts gehört.

Meine Config klappt sicher unter LILO - so wie wahrscheinlich deine unter GRUB.

LILO ist ja nur wichtig, wo er beim Aufruf von lilo die Files auf Platte findet... Wenn du LILO auf dem MD installierst, schreibt er ja in Wirklichkeit auf die drunterliegenden Platten - Bei Lilo muss man halt nicht so rumfrickeln wie bei GRUB, damit auf jeder Platte im Verbund auch ein Loader ist

Hi!

Ja das Pro0blem ist aber das einfach kein Bootloader gefunden wird

Im Rescue Mode kann ich auf das RAID und LVM zugreifen ... auch wenn ich erst alles wieder mounten muss.

Bei "#df"  zeigt er mir alle an:
/dev/mapper/SYS-ROOT / 1%
/dev/mapper/SYS-BOOT /boot 1%
/dev/mapper/SYS-USR /usr 1%
/dev/mapper/SYS-var /var 1%
/dev/mapper/SYS-HOME /home 1%
tmpfs /dev 1%

Wenn ich nun "#lilo" ausführe:
Warning: LBA32addressing assumed
Fatal: open /vmlinuz: No such file or directory

Wenn ich "#mount /boot" und dann "#df" ausführe:
/dev/mapper/SYS-ROOT / 1%
/dev/mapper/SYS-USR /usr 1%
/dev/mapper/SYS-VAR /var 1%
/dev/mapper/SYS-HOME /home 1%
tmpfs /dev 1%
/dev/mapper/SYS-BOOT /boot 9%
/dev/mapper/SYS-BOOT /boot 9%
/dev/mapper/SYS-BOOT /boot 9%

Wenn ich dann "#lilo" ausführe:
Warning: LBA32 addressing assumed
Added Linux *
Skipping /vmlinuz.old
The Master boot record of /dev/sda has been updated.
Warning: /dev/sdb is not the first disk
The Master boot record of /dev/sdb has been updated.
2 warnings were issued.

Die LILO Conf:
boot=/dev/md0
root=/dev/mapper/SYS-ROOT
raid-extra-boot=mbr-only
map=/boot/map
delay=20
default=Linux
image=/vmlinuz
label=LINUX
read-only
      append="quiet"
initrd=/initrd.img
image=/vmlinuz.old
label=LinuxOLD
read-only
optional
      appended="quiet"
initrd=/initred.img.old

10.08.2010, 12:47 Uhr - Editiert von n256, alte Version: hier

Aaaah... Du hast /boot unter LVM-Kontrolle - das darfst nicht!

OK alles klar!

Ich kann im Installer nach dem ich das RAID 1 ertsellt habe leider nur 1 Partition á 2 TB erstellen ... sprich kein /boot und dan erst das LVM ...

Woran kann das liegen?

10.08.2010, 13:51 Uhr - Editiert von n256, alte Version: hier

Ahem.

Zuerst 2 Partitionen pro Platte erstellen... (eine zB 1GB, eine mit Rest)
Dann 2 md's anlegen:
md0 zB für /boot
md1 für LVM2

md0 wie eine normale Partition mit FS drin behandeln
md1 wie eine normale Partition für LVM2.

Du musst also drunter die Partitionen haben und drüber mehrere MDs, nicht andersrum!

Danke!

Eh klar, total am Schlauch gestanden

Werd dann brichten ob System dann booted

Was zum Geier mache ich falsch?

LUNA:/# df -h
/dev/mapper/SYS-ROOT 184G 264M 174G 1% /
/dev/md0 939M 28M 864M 4% /boot
/dev/mapper/SYS-HOME 92G 188M 87G 1% /home
/dev/mapper/SYS-USR 92G 442M 87G 1% /usr
/dev/mapper/SYS-VAR 1,5T 374M 1,4T 1% /home
tempfs 443M 696K 442M 1% /dev

LUNA:/# cat /etc/lilo.conf
boot=/dev/md0
root=/dev/mapper/SYS-ROOT
raid-extra-boot=mbr-only
map=/boot/map
delay=20
default=Linux
image=/vmlinuz
label=LINUX
read-only
append="quiet"
initrd=/initrd.img
image=/vmlinuz.old
label=LinuxOLD
read-only
optional
appended="quiet"
initrd=/initred.img.old

sda1, sdb1 => RAID 1 => 1 GB => ext3 => /boot
sda2, sdb2 => RAID 1 => 2 TB => LVM => / - /var - /home - /usr

Lilo ist nun auf /dev/md0 installiert.

10.08.2010, 17:06 Uhr - Editiert von n256, alte Version: hier

root=/dev/mapper...

Zu dem Zeitpunkt gibt es ja noch keinen LVM...

Bei mir sieht das so aus:
root = /dev/ram0

in der Ramdisk
- werden die MDs hochgenommen
- und danach LVM2
- und erst danach ein pivot_root weiter (oder eben über real-root-dev - wie auch immer).

Hmmm... Du hast recht, deine Variante gibt es auch.

Wie weit bootet das Teil denn jetzt ? Noch immer nicht einmal den Kernel ?
Dann tippe ich weiterhin drauf, dass Windows von dem Teil auch nicht booten würde..

10.08.2010, 18:14 Uhr - Editiert von kombipaket, alte Version: hier

Hi!

Also ich hab Windows noch nicht probiert ... aber das es ein Intel Atom Board ist denke ich schon das es funktionieren würde ....

Windows brauchst du dazu gar nicht. Sowas wie z.B. memtest86 würde schon reichen. RAID usw. abbauen, dd if=memtest86.bin of=/dev/sda (und nochmal /dev/sdb). Vorsicht, deine Partitionstabellen usw. werden dabei überschrieben, das erste Dateisystem wird auch in Mitleidenschaft gezogen.

Direkt an den Anfang der Platte schreiben ohne Nootloader ohne alles. wenn du davon dann bootest, sollte direkt der memtest kommen

kommt da nichts dann ists vom bios / controller her einfach nicht bootfähig, und du wirst entweder dein bios konfigurieren müssen oder, wenns technisch einfach nicht gehen sollte, mit einem usb stick vorlieb nehmen müssen (nur zum booten, das system selbst kann ja trotzdem von den platten laufen)

kommt der memtest, müssen bootloader wie grub und lilo genauso funktionieren und du machst einfach iwas falsch...

Am SATA Controller hängt auch das DVD-Laufwerk ... und von dem kann ich ohne Probleme booten ...

11.08.2010, 02:09 Uhr - Editiert von n256, alte Version: hier

Stimmt - memtest war eine clevere Idee...

Wobei ich mir da nicht sicher bin... Muss da nicht ein gewisses Muster auf der Platte sein, damit der Rechner davon bootet ? Ist das bei memtest "inkludiert" ? Muss mal nachprüfen.

Bei mir klappt es zumindest so.

Hi!

Also Windows XP bootet

Nur wo liegt jetzt der Fehler ....

Das ist exht zu Mäuse melken!

Nachtrag:

System läuft jetzt!
Allerdings mit einem 3ware Controller (8006-2LP) und über den normalen PCI-Bus (32).

Normalerweise bin ich sehr interessiert an der Lösung solcher Probleme, jedoch hats nach 4 Wochen definitiv gereicht. Hab ich das System nur mit LILO ohne nachkonfiguration zum laufen gebracht. Trotz GRUB2 im installer wird dieser falsch konfiguriert.

Danke trotzdem für die tolle Hilfe!

LG
Nick

Haaalt!

Nachdem ich selbst vorhabe, ein System mit 2TB-Platten zu bauen und Debian draufzubringen... Bitte vorab Infos:

1.) WAS ging nun genau nicht? Nun hast ja den 3ware Controller (8006-2LP) und über den normalen PCI-Bus (32) - was hattest vorher ?

2.) Wie sieht deine lilo.conf nun aus ? (Bitte posten)

3.) Welchen Kernel verwendest Du ? ( uname -a )

4.) Hast du auch gptsync probiert ? Gibts als Debian-Paket, aus der manpage:

       gptsync  reads  the  GPT partition table on device and synchronises the
       legacy MBR partition table with the GPT partition table. The MBR parti‐
       tion table can hold only 4 partitions.

       Legacy bootloaders or operating systems that do not support GPT require
       an MBR partition table; this is typically the case when using  GRUB  or
       LILO on an Intel-based Apple machine.

5.) Kann es sein, dass GPT-Booten etwas mit BIOS zu tun hat ?
Weil es mit onboard-SATA scheinbar nicht klappte und jetzt schon ?

6.) Kann es sein, dass dir einfach die Treiber für den (Onboard)SATA-Controller in der initrd gefehlt haben ? Das würde erklären, warum er kein rootdev gefunden hat... Den LILO/Grub booten ja noch mit BIOS-Calls... Erst der Kernel nachher braucht ja die Treiber

04.09.2010, 07:37 Uhr - Editiert von kombipaket, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung