Ich habe gerade ein System wie dieses installiert:
ubuntu@ubuntu:~$ ls -l /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 10 2012-01-22 18:49 Boot -> ../../sda1
lrwxrwxrwx 1 root root 10 2012-01-22 18:49 ubuntu32 -> ../../sda2
lrwxrwxrwx 1 root root 10 2012-01-22 18:28 ubuntu64 -> ../../sda3
lrwxrwxrwx 1 root root 10 2012-01-22 18:49 Home -> ../../sda5
ubuntu@ubuntu:~$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 3582d70f-f4a5-484c-b14c-45cd740346b9 -> ../../sda1
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 741182a8-3f15-4dfd-994d-654c8a57a9e4 -> ../../sda2
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 1c415472-a770-4d76-be9f-27b8c1408e2a -> ../../sda3
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 3515d523-72a2-4e04-b7da-cb6a1fd572ef -> ../../sda5
lrwxrwxrwx 1 root root 10 2012-01-22 20:55 f1f1cd7e-30cb-44e7-9ef6-986a589e0045 -> ../../sda6
Ich brauche 32 und 64 Bit separat, damit ich die Treiberleistung auf beiden testen kann. Das Home-Verzeichnis ist freigegeben und jede Ubuntu-Version ist als /ubuntuXX unter der anderen Version gemountet. /boot verweist auf beiden auch auf /dev/sda1.
Wenn ich es sudo update-grubvon Ubuntu32 aus ausführe, läuft es einwandfrei, aber beim Booten von Ubuntu64 erhalte ich einen Fehler. initschlägt fehl und ich gehe davon aus, dass es am falschen Bittyp liegt. Sollte Grubs OS-Sonde nicht bitfähig sein? Wie kann ich diese beiden dazu bringen, ordnungsgemäß zu booten?
Ich habe grub-customizer von einer Live-Festplatte aus ausgeführt, /dev/sda3 als Root ausgewählt, im zweiten Schritt alle Partitionen ausgewählt und dann alle Einträge außer OS-Prober und Memtest entfernt. Das Ergebnis ist die angehängte grub.cfg. Sie listet jetzt /dev/sda2 als einzige Betriebssystemoption auf. In der grub.cfg ist die Root-UUID für jeden Eintrag auf /boot eingestellt.
grub.cfg:http://pastebin.com/Dkdxian4
fstab (beide):http://pastebin.com/3sUabYRY
Ich weiß, dass Grub2 alles automatisch generiert, Menüs und so, aber wie kann ich das alles einfach löschen und Einträge manuell hinzufügen (ich behalte diese Installation nicht lange, also muss ich mir wegen Kernel-Updates keine Gedanken machen)
Ich habe versucht, den /dev/sda2Eintrag problemlos zu reproduzieren, ihn aber angepasst, /dev/sda3aber das hat nicht geklappt. Ich habe es jedoch geschafft, denselben Fehler wie bei meinem ersten Versuch zu erhalten (es ist die Zeile direkt vor der Kernel-Panik run-init) .
Teil von grub.cfg aktualisiert:http://pastebin.com/DvfBhrBF
(null)
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom: ... done.
[ 3.402989] request_module: runaway loop modprobe binfmt-464c
run-init: /sbin/init: Exec format error
[ 3.406303] Kernel panic - not syncing: Attempted to kill init!
[ 3.406394] Pid: 1, comm: run-init Not tainted 3.0.0-15-generic #25-Ubuntu
[ 3.408290] [<c151a922>] ? printk+0x2d/0x2f
[ 3.408338] [<c151a800>] panic+0x5c/0x151
[ 3.408388] [<c104b564>] forget_original_parent+0x1e4/0x1f0
[ 3.408440] [<c10d3a48>] ? perf_cgroup_attach_task+0x20/0x20
[ 3.408489] [<c104b583>] exit_notify+0x13/0x140
[ 3.408536] [<c104bd8d>] do_exit+0x1ad/0x3a8
[ 3.408585] [<c1313850>] ? tty_write+0x228/0x228
[ 3.408632] [<c104c098>] sys_exit+0x18/0x28
[ 3.408680] [<c152e424>] syscall_call+0x7/0xb
Ich fange an zu glauben, dass es mit den Kernel-Images zu tun hat, die sich im /boot-Verzeichnis befinden.
Ok, jetzt bin ich sicher, dass es daran liegt, dass eine Partition 32-Bit und die andere 64-Bit ist.
Abbildung 1: Auszug aus /boot/grub/grub.cfg:
linux /vmlinuz-3.0.0-12-generic root=/dev/sda2
initrd /initrd.img-3.0.0-12-generic
Abbildung 2: Auflistungen von /ubuntu64/vm* und /ubuntu32/vm*
me@GAMMA:~$ ls -l /vm*
lrwxrwxrwx 1 root root 29 2012-01-23 20:41 /vmlinuz -> boot/vmlinuz-3.0.0-15-generic
lrwxrwxrwx 1 root root 29 2012-01-22 13:05 /vmlinuz.old -> boot/vmlinuz-3.0.0-12-generic
me@GAMMA:~$ ls -l /ubuntu32/vm*
lrwxrwxrwx 1 root root 29 2012-01-22 12:41 /ubuntu32/vmlinuz -> boot/vmlinuz-3.0.0-15-generic
lrwxrwxrwx 1 root root 29 2012-01-22 12:22 /ubuntu32/vmlinuz.old -> boot/vmlinuz-3.0.0-12-generic
Abbildung 3: Magic File Type von /boot/vmlinuz-3.0.0-12-generic
/boot/vmlinuz-3.0.0-12-generic: Linux kernel x86 boot executable bzImage, version 3.0.0-12-generic (buildd@creste, RO-rootFS, root_dev 0x801, swap_dev 0x4, Normal VGA
/boot/vmlinuz-3.0.0-15-generic: Linux kernel x86 boot executable bzImage, version 3.0.0-15-generic (buildd@creste, RO-rootFS, root_dev 0x801, swap_dev 0x4, Normal VGA
Hier ist dierealKicker:
me@GAMMA:~$ sudo find / -name "vmlinuz*"
/boot/vmlinuz-3.0.0-12-generic
/boot/vmlinuz-3.0.0-15-generic
/vmlinuz.old
/vmlinuz
/ubuntu32/vmlinuz.old
/ubuntu32/vmlinuz
Das ist der einzige Kernel auf meinem System! Wie ist das überhaupt möglich? Ich verwende derzeit 64-Bit ( /dev/sda3ist /und unamemeldet 64-Bit)!
Ich habe den Paketinhalt auf packages.ubuntu.com geprüft und die am64-Version von linux-image-3.0.0.15-generic ist /boot/vmlinuz-3.0.0-15-genericals Datei aufgelistet, also habe ich Folgendes ausgeführt:
me@GAMMA:~$ sudo openssl dgst -md5 /boot/vmlinuz-3.0.0-15-generic > ~/3.0.0.15x86
me@GAMMA:~$ sudo apt-get install --reinstall linux-image-3.0.0-15-generic
(Output Omitted)
me@GAMMA:~$ sudo openssl dgst -md5 /boot/vmlinuz-3.0.0-15-generic
MD5(/boot/vmlinuz-3.0.0-15-generic)= f56839a4642eb97e06e5efb0bc74f4dc
me@GAMMA:~$ cat ~/3.0.0.15x86
MD5(/boot/vmlinuz-3.0.0-15-generic)= f56839a4642eb97e06e5efb0bc74f4dc
me@GAMMA:~$ sudo openssl dgst -md5 /boot/vmlinuz-3.0.0-15-generic > ~/3.0.0.15x86
Der Linux-Kernel verhält sich also sehr ähnlich wie der Mach-Kernel in OSX, da es sich um eine 32-Bit-ausführbare Datei handelt, die bei Bedarf in den 64-Bit-Modus wechselt. Die Frage ist dann, warum ich einen Fehler über „Exec-Formatfehler“ erhalte?
Dieser Beitragscheint jedoch darauf hinzudeuten, dass runaway loop modprobedie Kernel Panic darauf hinweist, dass es sich tatsächlich um ein 32/64-Bit-Problem handelt. Grub muss eine Möglichkeit haben, dem Kernel die Bitlänge mitzuteilen, vielleicht befindet sie sich in einer zugehörigen Datei in /boot. Das werde ich mir morgen ansehen.
Kurzes Update:
Die Hashwerte für die 32-Bit- und 64-Bit-Kernel sind unterschiedlich, aber die Datei meldet, dass es sich bei beiden um x86-Kernel handelt.
< MD5(/boot/vmlinuz-3.0.0-15-generic)= f56839a4642eb97e06e5efb0bc74f4dc
---
> MD5(/boot/vmlinuz-3.0.0-15-generic)= cee6cd7db9016ee8531be92504ac802b
Ich muss also herausfinden, wie ich den Kernel an einem anderen Ort als /boot installieren kann, damit die beiden Kernel sich nicht gegenseitig beschädigen ...
Antwort1
(ungetestet) Lösung:
Mounten Sie /dev/sda1 nur für eine Partition auf /boot und lassen Sie /boot für die andere Partition bestehen. Die Kernel überschreiben sich nicht gegenseitig und dann ist Grub vielleicht auch nicht verwirrt, warum es zwei Betriebssysteme, aber einen Kernel gibt.