Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: Saint on 2010/10/23, 10:13:02
-
Dieses Upgrade führt bei mir zu ein nicht Bootbaren System
"vmlinuz not Found"
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg836356.html
-
nicht nur bei dir, aber nicht bei allen.
ich versuch gerade rauszukriegen warum.
greetz
devil
-
ist / verschlüsselt?
greetz
devil
-
alle user bei denen der bug bisher auftrat, haben eine separate /boot partition.
hier hilft es aus der inird zeile der grub.cfg das /boot zu entfernen.
greetz
devil
-
Hallo,
bei hatte es nur geholfen, wenn ich aus der linux Zeile das /boot auch noch entfernt habe.
Habe / verschlüsselt und /boot als Extrapartition auf einem USB-Stick
Gruß
postkutscher
-
Hi zusammen,
bei mir half nur "/boot" aus der linux-Zeile und aus der initrd-Zeile zu entfernen, dann konnte ich wieder booten. Mein System läuft komplett unter dem LVM einschließlich Rootfielsystem (/) und extra Bootpartition (/boot).
$ df -h
Dateisystem Size Used Avail Use% Eingehängt auf
/dev/mapper/VGsys-LVroot
1008M 425M 532M 45% /
tmpfs 1,9G 8,0K 1,9G 1% /lib/init/rw
udev 1,9G 248K 1,9G 1% /dev
tmpfs 1,9G 312K 1,9G 1% /dev/shm
/dev/mapper/VGsys-LVboot
248M 61M 175M 26% /boot
/dev/mapper/VGsys-LVhome
5,0G 3,5G 1,5G 71% /home
/dev/mapper/VGsys-LVopt
1008M 182M 827M 19% /opt
/dev/mapper/VGsys-LVtmp
504M 17M 488M 4% /tmp
/dev/mapper/VGsys-LVusr
4,0G 2,7G 1,3G 68% /usr
/dev/mapper/VGsys-LVvar
3,0G 1,7G 1,4G 56% /var
/dev/mapper/VGsys-LVmisc
50G 45G 4,9G 91% /mnt/misc
/dev/mapper/VGsys-LVmusic
40G 32G 8,2G 80% /mnt/music
/dev/mapper/VGsys-LVphoto
15G 11G 4,1G 73% /mnt/photo
/dev/mapper/datavg-LVvm
90G 49G 42G 55% /mnt/vm
/dev/mapper/datavg-LVbackup
360G 130G 230G 36% /mnt/backup
EDIT: Habe aber trotzdem meine Sicherung wieder zurückgespielt und werde GRUB auf HOLD setzen, solange der Bug nicht behoben ist.
-
cd /boot && ln -s . ./boot
wäre pfadlogisch. Diesen symbolischen Link legt auch jede Distri normalerweise schon bei der Installation an!
-
ich weiß, dass dieser Gedanke jetzt nicht besonders produktiv ist... aber es ist schon unglaublich, wie viele Probleme wir im sidux und jetzt im aptosid Forum seit Monaten mit Grub2 haben.
1. Es ist zu komplex
2. Es ist zu fehleranfällig
3. Es ist schwerer bedienbar (
Früher habe ich ne Partition einfach mit dd geklont und auf einem anderen Rechner laufen lassen, heute scheue ich davor zurück, weil einen Grub neu zu installieren länger dauert, als eine Live Cd einzuspielen...
auch wenn ich gerne neues probiere, vlt. auch weil grub an einer sensiblen Stelle im System sitzt, ich sehe mich nach Grub 1 zurück ;-)
-
Hallo Lanzi,
zu Grub2 stimme ich auch regelmäßig Lobeshymnen an ;-)
- reproduzierbar werden Win und Win Restore Partitionen falsch erkannt, das kann üble Folgen haben, weil manche Restore Installationen ungefragt sofort loslegen, den MBR platt machen und dann nach dem alten Schema Windows neu aufsetzen ohne Rücksicht auf Verluste
- aus einer cfg Datei muss etwas herauskopiert werden, in eine custom hineinkopiert werden, damit Sachen wirksam werden, ein schlechter Scherz ist das
- das Verdongeln von grub2 mit einem schönen Hintergrundbild wird ein editorisches Abenteuer
Und für mich ist es zweitrangig, ob Grub2 theoretisch viel mehr tolle Möglichkeiten bietet, wenn im Konkreten damit noch so viele Leute arge Schwierigkeiten haben.
Viele Grüße,
Holger
-
Ich bin sehr glücklich mit grub2, allerdings muss ich zugeben das ich etwas anders vorgehe.
Ich habe als ich auf grub2 umgestiegen bin ein gfx-boot menu aufgesetzt, und grub2 direkt auf hold gesetzt. Das werde ich solange so beibehalten, bis gfx in grub2 integriert ist, oder der hold andere upgrades behindert.
-
æHolger:
Na dann sind wir ja schon zwei :-)
Früher war halt doch alles besser... Jetzt haben wir den Beweis ;-)
Nee, im Ernst, ich habe den Einruck, dass grub2 gerade so langsam "explodiert", Die Probleme nehmen scheinbar zu, nicht ab. Ich habe übrigens auch eine seperate Bootpartition... mir grauts vorm nächsten DU...
Wenn jemand den Fehler nachvollziehbar eleminieren kann, wäre es schön, hier eine Lösung zu finden!
-
Hi Lanzi,
wenn ihr noch nicht in die Falle gelaufen seit (wie ich) setzt grub auf HOLD bis der Bug gefixt ist.
# echo grub-common hold | dpkg --set-selections
# echo grub-pc hold | dpkg --set-selections
@all: Gibt es den eine brauchbare Alternative zu Grub2?
EDIT: Hat jemand schon mal den SyMon Bootmanager (http://www.symon.ru/usr/ger/about.shtml) ausprobiert?
-
Also ich hatte keine Probleme mit grub2 bisher.
Das nur zur Info ;)
-
@bluelupo:
das wollte ich schon immer lernen -also etwas auf "hold" setzten :-)
1. Mit Grub auf hold kann ich trotzdem den neuen Kernel installieren?
2. wie setzte ich grub auf "unhold"
Danke
-
lanzi,
hold:echo package hold|dpkg --set-selections
unhold:echo package install|dpkg --set-selections
show holds: dpkg --get-selections | grep hold
greetz
devil
-
cool. Danke!
-
Also ich hatte keine Probleme mit grub2 bisher.
Das nur zur Info ;)
ich kann mich da anschließen, habe aber keine Verschlüsselung ud keine separate /boot-Partition.
Mit dem d-u warte ich troztzdem mal ein wenig.
-
Entwarnung: grub-pc_1.98+20100804-7 ist in den repos.
http://http://packages.debian.org/changelogs/pool/main/g/grub2/grub2_1.98+20100804-7/changelog
greetz
devil
-
devils link ist fehlerhaft eingetragen...
hier der link ohne umtippen ;)
http://packages.debian.org/changelogs/pool/main/g/grub2/grub2_1.98+20100804-7/changelog
achja und danke für die info!
nun also wieder un-holden!
---ein http:// zuviel-----
http://http://packages.debian.org/changelogs/pool/main/g/grub2/grub2_1.98+20100804-7/changelog
@devil: kannst mein post auch löschen, kann nur deinen beitrag nicht editieren ;)
-
Hi, ich bin scheint's zu blöd oder begreife aber die Welt nicht mehr. Wo sind denn die großen Probleme mit Grub2 - das Teil startet halt eine Betriebssystem, genau wie der alte Grub auch. Wenn man jetzt mal ganz böse ist, schaltet man diese dösigen Automatiken aus und wandelt einfach mal die heilige grub.cfg manuell in etwas um, was ein normaler Mensch unbetrunken lesen kann. Das soll ja so in etwa die Fahrtrichtung dessen sein, was momentan in der Revisonskontrolle schlummert und Opfer sucht. Dass die Scripts in /etc/grub.d in jedem Fall mit mehr als einem Kernel und Spezialkonfigurationen nicht einmal das Wort "Totalversagen" verdienen, brauche ich wohl nicht gesondert erwähnen, habe damit in den letzten Tagen ein über Stunden währendes Vergnügen gehabt.
Wenn man aber diesen Schrott abschaltet, macht Grub2 genau das, was es soll - Es startet so ziemlich jede denkbare und undenkbare Systemkonfiguration - ohne jegliche Probleme und in richtig schick. Wer allerdings nicht wirklich abenteuerlustig ist, wird an den jetzigen und kommenden Versionen erst mal nicht die große Freude haben. Die möglichen Fehlerquellen in Grub steigen noch weiter an, es wird im Code geholzt, dass ein Kettensägenmassaker dagegen harmlos wirkt und mit jeder Version gibt es neue schöne Seiteneffekte.
Ich mag mich irren, aber die liegen meist in den Erstellungsscripten - Das würde im Endeffekt als stabile Zwischenbasis bedeuten:
- 00_header funktioniert eigentlich recht zuverlässig und ohne große Möglichkeit, etwas zu zerstören
- 05_debian_theme ist eigentlich die Zuverlässigkeit in Scriptform
- 10_linux geht eigentlich ohne akribische Kontrolle schon gar nicht mehr, der Output ist nur noch als relativ gute Vorlage zu gebrauchen
- 20_linux_xen ist für die meisten unter uns eh über, funktioniert aber schon erstaunlich gut, ist aber immer allenfalls als sehr gute Vorlage zu gebrauchen.
- 30_os-prober ist sehr gelungen, wenn man dann wirklich mal einen ordentlich gebauten Eintrag findet. Auf gut Deutsch eine reine Katastrophe, die in der jetzigen Form nur noch dazu dienen kann, jeden in irgendeiner Form auf dem System befindlichen Kern zu finden. Was dann draus gemacht wird, graust die Sau oder reizt zumindest mich zu hysterischen Lachkrämpfen.
- 40_custom ist wieder sehr gelungen
- 41_custom ist auf jeden Fall übersichtlich, wozu man das allerdings zwingend benötigt, erschließt sich mir nicht unbedingt.
Mit chmod 644 10* 20* 30* und cp 40_custom 09_meins und editieren dieser Datei hat man also eine Chance auf ein funktionierendes System bei nicht vollständig abgeschalteter Automatik. Auf jeden Fall kann man dann noch die zu verwendenden Kernel und Hintergründe, nicht zu vergessen die Bildschirmauflösung relativ sicher über die /etc/default/grub festlegen - das ist doch schon mal ein Anfang.
-
@agaida: Schreib doch mal deine Lösung (im Detail) dazu ins Wiki. Wäre doch für alle eine praktikable Lösung.
-
Kann ich gerne machen. aber frühestens übermorgen. Das Rumgehacke mit grub2, raid und lvm2 hat mich mehr Zeit gekostet, als ich eigentlich dafür angesetzt hatte. Diesmal war Grub sogar fast unschuldig, da sass der Fehler vor dem Computer ;).
-
...
Mit dem d-u warte ich troztzdem mal ein wenig.
Nach d-u hier alles normal!
-
agaida,
die probleme mit grub2 sind die upgrades.
das mag einerseits am noch relativ jungen lebenszyklus von grub2 liegen.
andererseits aber (wie beim jetztigen bug), dass anscheinend nicht ausgiebig genug getestet wird vor einem upload.
hätte man mit einer eignenen /boot partiton getestet, hätte man den bug entdeckt.
greetz
devil
-
Ich habe meine experimentale Maschine und gleichzeitig Entwicklungsmaschine in der letzten Woche komplett überarbeitet. Da lagen also noch etliche Versionen Arch, Ubuntu, debian und Installationsleichen, Projektischerungen etc. pp drauf rum. Nach einem kurzen Stutzen habe ich dann mal ca. 35 Einträge aus dem System durch schnödes Löschen entfernt. Interessanterweise waren sogar einige vollkommen richtige Starteinträge zwischen dem Schrott. Insgesamt 3x 100% und 6x geht so. Viele Kernel wurden vom prober doppelt und dreifach gefunden und stumpf in die Liste aufgenommen. Es hätte noch mehr Einträge gegeben, wenn zu diesem Zeitpunkt LVM schon richtig funktioniert hätte. Ich habe das jetzt auf 8 wirklich richtige Einträge eingedampft und das dann in der 9_meins gelagert. Ist ja auch nicht unbedingt ein Normalfall, im Laufe der Zeit hatte sich aber schon so einiges angesammelt. Böswilligerweise wurden auch noch die ganzen virtuellen Maschinen mit aufgenommen, an denen ich mit verschiedenden Kerneln und Distributionen probiert hatte - das Chaos war perfekt. Ich hab dann einfach einen für solche Fälle vorbereiteten Bootsektor und eine unverfuckelte grub.cfg genommen. F12 sei dank. Die ganze Situation entbehrte aber nicht einer gewissen Komik.
-
Hallo @agaida,
sei mir nicht böse aber Deine Argumentation pro grub2 liest sich so:
Es gibt keine großen Probleme mit Grub2, man muss zwar:
- entgegen der Empfehlungen die cfg bearbeiten
- Automatismen abschalten
- die Skripte in /etc/grub.d sind zwar Schrott
- 00* ist gut, 05* ist zuverlässig, 10* muss ständig akribisch kontrolliert werden, 20* ist immerhin gute Vorlage, 30* eigentlich katastrophal, 40* ist gelungen, 41* überflüssig
- der ganze Kram kostet ziemlich viel Zeit
Aber sonst macht Grub2 das, was er soll. ;-)
Viele Grüße,
Holger
-
@holgerw:
Klingt nicht positiv genug? Wenigstens mit dem manuellen bearbeiten hast Du unrecht. Knallst Du funktionierende Konfigurationen in die 09_ oder 40_, erübrigt sich die manuelle Nachbearbeitung. Für einen ganz "normalen" Rechner mit nur einem Betriebssystem liegt die Erfolgsquote auch wesentlich höher.
Über diesen unvollständigen Schrott der Warnung lasse ich mich an dieser Stelle nicht aus, dass heisst vollständig: Sie sollten die grub.cfg auf keinen Fall manuell ändern, es sein denn Sie wissen ganz genau, was sie tun. Das stammt noch aus den alten RFCs zur Sprachregelung bei w3c und hat durchaus seine Berechtigung. Da ich aber weiss, was ich tue und Admin bin, darf ich das.
Dieser blöde Satz führte schon mehr als einmal im Supportfall dazu, dass Hilfe nicht angenommen wurde, weil die Leute einer nicht funktionierenden grub.cfg mehr glaubten, als dem Supporter. ;) Ist ja auch kein Problem. Ich bin trotzdem bekennender Fan von Grub 2.
Wenn Grub2 mal fertig ist, dann ist der richtig toll. Bis dahin ist halt ein wenig Leiden angesagt. So wirklich zum Tragen kommen die Vorteile im Fehlerfall wirklich noch nicht. Grub2 ist aber trotzdem schon so weit, dass man ihn gnadenlos einsetzen und unterstützen sollte. Das mit den Scripten sehe ich ähnlich, wie eine GUI für den Apachen oder ähnlich.
-
@agaida
Wie schon an anderer Stelle vorgeschlagen. Schreib doch bitte eine Anleitung, in der du all deine Erkenntnisse zu einer funktionierenden Grub 2 einfließen lässt. Damit wäre vielen Lesern hier sicher geholfen.
Danke
-
die probleme mit grub2 sind die upgrades.
Genau. Ich habe im Sommer ein wenig die Bugs verfolgt, die Colin Watson bearbeitet hat. Die halb durchgeführten Upgrades waren in der letzten Zeit sein Hauptproblem: Die Änderungen bei einem Umstieg von grub1 auf grub2 wurden fast nie vollständig durchgeführt.
Die einfachste Konfiguration von Grub2 ist, den os-prober zu deinstallieren und dann per Hand in
/etc/grub.d/40_custom#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
#
menuentry "Debian sda3" {
search --no-floppy --label --set debian
linux /vmlinuz root=LABEL=debian quiet noresume ro nomodeset
initrd /initrd.img
}
menuentry "Desktop openSUSE 11.3" {
search --no-floppy --label --set suse113
linux /boot/vmlinuz root=/dev/disk/by-label/suse113 nomodeset quiet vga=0x317
initrd /boot/initrd
}
menuentry "Ubuntu maverick sda8" {
search --no-floppy --label --set maverick
linux /vmlinuz root=/dev/sda4 quiet ro splash nomodeset
initrd /initrd.img
}
Und gut ist nach einem ersten "update-grub"
ohne je wieder ein update-grub machen zu müssen. Mit diesem Beispiel wird gezeigt:
- wie man mit Labels auf verschiedene Weise verfahren kann. Labels finde ich übersichtlicher als UUIDs.
- openSUSE macht die Symlinks zu neu installierten Kerneln etwas anders als Debian basierte Distributionen.
- Zusätzliches "set root" kann man sich in den Menu Einträgen sparen. Nur ein "set root" wäre allerdings schneller beim Booten als "search".
- zu beachten: Wie verfährt Debian bei einer extra /boot Partition? Sind die Symlink dann auf /boot, würde der oben aufgetretene Bug sich nicht manifestiert haben mit meiner Methode.
-
weiteres bitte im experimentellen teil.
dies ist meilenweit von supportbar entfernt und hat nichts mit der upgrade warnung zu tun.
danke
greetz
devil
-
Ich habe diese einfachst Methode so genau beschrieben, damit agaida es im Wiki verwenden kann. Da müsste dann nur noch mit rein:
tune2fs -L meinLabel /dev/sdaX